RE: Re: dynamics: comment about MBdyn...

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

> [...]
> > > And where is my guarantee that Dymola will not start to 
> use them for that
> > purpose...?
> > 
> > With any standard, it is entirely possible that a vendor will chose to not
> > conform to the specification.  Most of the time, such non-conformance is
> > simply an undisputed bug and gets resolved.  
> 
> It is _not_ a bug to put anything you like in annotations...

But an implementation is non-conformant if uses that information for anything behavioral.

> [...]
> > > Where is my guarantee that I can change software vendors without
> > > loosing my investment in models?
> > 
> > That is what the standard attempts to define.  Does the 
> Modelica Association
> > have a para-military force that will swoop in and compel a 
> vendor at gun
> > point to conform to the specification or else?  No.  Do you 
> have any real
> > guarantee that Japan won't invade Europe and force you all 
> to work a slave
> > labor processing sugar beets?  No.  
> 
> This is completely out of context... You don't respond to the core of
> my objections, you are just ridiculising them.

No, I'm just pointing out that there are no real guarantees in life so the answer to *any* question of "can you guarantee that this will or will not happen is 'no'".

> The core question to which I would like a "yes" or "no" answer is the
> following: 
> 
>   Is it possible that company A provides a fully correct Modelica
>   file, while this file is practically useless to a user of 
>   company B's software, because the annotations in A's Modelica file 
>   contain useful but proprietary coded features?

If fully correct means only syntactically correct then this is possible.  If fully correct means semantically correct, then the answer is that it is not possible.

> [...]
> > > The common practice in the feature-bloated IT industry 
> has proven time
> > > and again that this is what is going to happen, sooner or later...
> > > Unless the standard is complete and guaranteed.
> > 
> > I will not tell you that the Modelica specification is perfect.  In fact,
> > the Modelica specification is a living document to address deficiencies as
> > they are identified.  I would be very interested in knowing about *specific*
> > cases where the specification is incomplete or ambiguous.
> 
> I can not believe my eyes :-) Now you ask for possible problems with
> the Modelica specification

No, I asked for specific examples of where the specification was **incomplete** and/or **ambiguous**.  I realize that you have many ideas about how it could be done differently, but that is not the same thing.  I cannot think of issues you have raised that relate to these two particular attributes (which you introduced in to the discussion).

> while, for many emails already, I have been giving you concrete examples
> of how the annotation feature can lead to possible abuses...

Abusable != Incomplete and Abusable != Ambiguous

> My concrete suggestion is to limit the Modelica specification to what
> it really does very well: to encode information that leads to a set of
> physically correct DAEs. It can still provide hooks for extensions
> (such as exporting the _names_ of objects, or the events that it uses
> in its DES specification), but it should not try to specify these
> extensions in the file format itself.

The decision to include annotations for meta-data was a design decision and does not make the language incomplete or ambiguous.  It just means it doesn't conform to your desires or aesthetics.

> Anyway, I plan not to continue this discussion any further. It has
> been very interesting, but we begin to repeat ourselves, so we should
> move on with other things :-)

I'm actually quite happy to have had the discussion because even if I don't convince people, I am satisfied if they at least give me a chance to fully explain my position (which I have had ample oppportunity to do in this forum).

> Herman

--
Mike