Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Harmonize FMI 3.0 and eFMI array definition #625
In FMI 3.0 modelDescription.xml file, the dimensions of an array are defined as:
In eFMI production code manifest file, the dimensions of an array are defined as:
These definitions should be harmonized.
The production group argues:
This is not true. In FMI 2.0 e.g. the element index is used to reference the
What parser does that?
As long as there is a "sequence" in the xsd, the order is preserved.
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.
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).