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

On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

[...]
> So if I understand your assertion, any standard that is not *DEFINED* by an
> open source implementation in code (as opposed to a document describing the
> standard) is not truly a standard?!?

No! Take the PDF example. What I say is the following: the Modelica
organisation has made the choice to allow that it possible to
interpret the same Modelica file in different ways, depending on the
software that processes the code. I have not said that this is the
case now, but I pointed out how the current specification could be
misused. That's all. No more, but also no less.

[...]
> > Nothing  prevents one from using them to affect behaviour...
> 
> This is completely incorrect.  The semantics defined in the specification do
> not describe any transformation where information in an annotation enters
> into the process that generates the hybrid system of DAEs.

Ok, good to know this! Anyway, I should check again, because there is
a big difference between "it does not describe" something, and it
"prevents" something. 


> > (For example (_your_ example) using an annotation to define
> > dependencies between variables in the model.)
> 
> I showed that you could use annotations to relate a type definition in
> Modelica to a piece of meta data.  Nowhere, in what I described, was there
> any suggestion that this should affect any behavioral aspect of the model.
[...]
> In summary, annotations *DO NOT* affect the semantic processing...ever.

Ok, that's important! But again, how can I be sure about that? And
that this will not be the case in the future? Please respond to my
example that Dymola (or some other company) could begin to use
annotations to encode proprietary data in order to gain competitive
advantages?  Please respond to my example that introducing a special,
proprietary graphical representation in the annotations would also put
fair competition in danger. What use is a standard if I receive a file
and my brand new commercial program says it doesn't understand parts
of the file, while I paid for a "Modelica compliant" product...?

[...]
> > 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...

> You run the same risk of non-conformance with an open-source
> implementation.  
Unless it is the reference implementation. (Not that I plead for
having standards that can only be checked with reference
implementation, oh no!)

[...]
> > 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.

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?

Is this a correct statement, or am I wrong? I hope I am wrong, but you
haven't given me any convincing argument.

As I said, practice has proven that the situation sketched above leads
to competition fraude: all that Microsoft had to do to make users of
WordPerfect get doubts about their product was displaying a message
at WordPerfect startup time, saying that WordPerfect was not fully
compatible with the Windows platform, with possible loss of data as a
result... The incompatibilities of the web browsers is another,
perfectly analogous, situation.

> If you had compliant Modelica models and
> your vendor suddenly decided to force you to mix annotation meta-data with
> behavioral data could you switch to another tool to avoid this
> perversion...yes.
Indeed. But this is not how it works in practice: vendors "innovate",
making proprietary extensions with new features, creating a lock in
long before users realise what is going on. 
Look at the PDF situation on the one hand, and the HTML, Word
situation on the other hand; it's obvious which standard is really a
standard, in the sense that it _unites_ multiple vendors instead of
_separating_ them. 


[...]
> > 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, while, for many emails already, I have
been giving you concrete examples of how the annotation feature can
lead to possible abuses...
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.

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 :-)

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480