Is it okay for XML element order to matter?

Hello, I have created a flexible network interface block for Simulink, written in C (in the form of a CMEX block) that is XML-configurable.  Part of my XML format is as follows, for example:

<Reads>
<Read name="charge" type="INT32" ip="127.0.0.1" port="2501" register="23">
<Read name="voltage" type="INT32" ip="127.0.0.1" port="2501" register="27">
<Read name="level (ft)" type="INT32" ip="127.0.0.1" port="2501" register="29">
<Read name="speed (ft/s)" type="INT32" ip="127.0.0.1" port="2501" register="24">
</Reads>

What my block does is work down the list, collect the four values from the network, and then populate a run-time-sized "vector" (ie an array that is passed between my C code and the simulink model) with the four values [charge, voltage,level,speed].  The simulink must be designed to extract the four engineering values in this order and do something with them.  So this is a "contract" between the simulink design and the XML content.  The idea is that if you make changes to the system you can modify the list of gathered values without changing the C code, you just have to update the XML and the simulink to handle the gathered data.

Make any sense?

In any case, I was very proud to have made the C code "futureproof" (ie not have to be changed again, since it was a pain to change through the CMEX editor) with this flexible interface -- and be able to do anything needed by working with just Simulink and XML.   But I am getting robust push back on the fact that the order of those four nodes matter (ie if you mix up the order of two elements it will not work correctly).  The client feels that this isn't standard XML if the order matters, and feels that it is a maintainability issue for the author of the XML to get the order perfect (ie if they swap two rows then the values get crossed).

They would like to build in some sort of lookup table or index attribute so that the order of the nodes can be mixed up, but some intelligence on the C or Simulink side will put them in the proper order.

I think this will add needless complexity.  There is no way around the implied contract, no way to really reduce the maintenance burden, at best just move it around.

So any reactions?  Is the burden of getting the order correct too onerous?  And/or have I "broken a rule" by making order matter within my XML elements?
RonMexicoAsked:
Who is Participating?
 
Carl TawnSystems and Integration DeveloperCommented:
What you are dealing with in your document are Mixed content elements. What the specification says is:

3.2.2 Mixed Content

[Definition: An element type has mixed content when elements of that type may contain character data, optionally interspersed with child elements.] In this case, the types of the child elements may be constrained, but not their order or their number of occurrences:
But, as I mentioned earlier, most parsers will honour the order in the document, but it isn't guaranteed.
0
 
zc2Commented:
I think you should not worry. The nodes will be read in the same order as they are present in the XML file. If you still in doubt, you could add an incrementing index attribute to the elements and verify the order against it while doing the reading.
0
 
RonMexicoAuthor Commented:
Is there anything about this that is "nonstandard" XML?
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
zc2Commented:
Yes, your XML is not well-formed. The read elements should close themselves, like
<Read name="speed (ft/s)" type="INT32" ip="127.0.0.1" port="2501" register="24"/>
(Note the slash in the end).
Everything else looks fine.
Whatever method will be used to read the XML (event based or loading into a tree structure) the sequence of the elements will remain unchanged.
0
 
RonMexicoAuthor Commented:
Thanks zc2, that was just a typo.

I appreciate the input.  If you don't mind I'll leave this open a little bit to see if anyone has a different (or same) opinion... I'm trying to build an argument that we haven't done anything improper and the more opinions, the better.
0
 
zc2Commented:
sure
0
 
Carl TawnSystems and Integration DeveloperCommented:
Your client does kind of have a point - XML parsers do not guarantee the order in which nodes are retrieved. Generally they will pull them in the order they are in the document but it isn't guaranteed that they will.

An extra attribute to denote a sequence would remove the issue. I'm guessing your client just wants something more definitive in the document that explicitly states the sequence the nodes are intended to be interpreted in.

You need to remember that XML purely describes the data, there is no implied ordering or formatting associated with it.
0
 
RonMexicoAuthor Commented:
Carl, thank you.  If that's true then I'll have to do what the client says.

I'm surprised though, that XML spec wouldn't guarantee that.  If they did then order could matter, it would be up to the application... And it wouldn't harm the majority of applications for which it doesn't.

Do you have a reference for that non-guarantee, by the way ?  Thanks again.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.