Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmonize FMI 3.0 and eFMI array definition #625

Open
MartinOtter opened this issue Sep 23, 2019 · 4 comments

Comments

@MartinOtter
Copy link
Member

commented Sep 23, 2019

In FMI 3.0 modelDescription.xml file, the dimensions of an array are defined as:

image

In eFMI production code manifest file, the dimensions of an array are defined as:

image

These definitions should be harmonized.

The production group argues:

  • Elements are not ordered in xml, and theoretically an xml parser can provide the dimension definitions in any order. For this reason number is given to uniquely define the number of the dimension (so that it does not depend on the ordering of the definition on the xml-file).
  • start is a very unusual description for an array size. The usual notation is size

@joergn, @Robert.Reicherdt

@t-sommer

This comment has been minimized.

Copy link
Collaborator

commented Sep 23, 2019

Elements are not ordered in xml

This is not true. In FMI 2.0 e.g. the element index is used to reference the <ScalarVariable> elements from the <ModelStructure> element.

and theoretically an xml parser can provide the dimension definitions in any order.

What parser does that?

@jnjaeschke

This comment has been minimized.

Copy link

commented Sep 23, 2019

https://stackoverflow.com/a/37831330

As long as there is a "sequence" in the xsd, the order is preserved.
But this "enforces" all parsers to know about the xsd file.

Generally speaking, I think relying on the order of elements in the xml tree is not elegant. Explicitly enforcing the right order by using an "index" attribute clears things up for everyone. And then it doesn't matter if you may use a bad xml parser.

@pmai

This comment has been minimized.

Copy link
Collaborator

commented Sep 23, 2019

XML elements are ordered (in document order, see the XML standard) quite regardless of XML Schema or any other specification mechanism that is used to describe the document syntax. So any parser that does not preserve the order of XML elements is not an XML parser, but something else.

There is no need to have redundant information here, it would in fact make the situation worse, because now you have to specify that XML element order must be disregarded, and/or that generators need to emit XML elements in the order of their index attribute values, and of course you introduce new error situations when generators create lists with missing or duplicate dimensions.

So please disregard people arguing about XML elements not having an order, that is a myth. Attributes are unordered, but elements have a well-defined order (remember that XML was derived from SGML (born as GML) which was intended as a generalized document markup language, where obviously the order of content matters).

@andreas-junghanns

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2019

We have had this argument too many times before. And we use the XML order already, so even if inconvenient, let´s not introduce a new way of doing things (and follow, again, the excellent arguments from above).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.