In XML, is order important?

Is the order that elements of a common parent appear in XML a meaningful piece of data captured by the XML document, or is order not specified as being meaningful? For example, consider the two XML documents:

<people>
 <person name="sam"/>
 <person name="juni"/>
</people>

and

<people>
 <person name="juni"/>
 <person name="sam"/>
</people>

Are these documents considered to represent identical data, or is the difference in order captured?

Order of elements is significant in XML, so in your example the two documents are different. Attribute order is not significant, though.

<people>
  <person name="kathy" id="1"/>
</people>

This is exactly the same as:

<people>
  <person id="1" name="kathy"/>
</people>

They are not identical - Whether the sequence matters is up to the program or user that processes it. For example, the sequence of elements in an XHTML document determine how they are displayed in a browser, and search engines use the position in the document to judge relative importance of the data.

The order is potentially important, but it depends on what's being transmitted.

In XHTML, for example, the order is extremely important - if you had sibling paragraphs in a random order, it would be very confusing!

In many other cases, it's unimportant.

XML is just a way of representing a tree of nodes. XML itself says that the order is important: APIs must preserve the order, for example - but it's up to whatever produces/interprets the data to really care about the order or not.

The XML specification effectively has to "err on the side of ordering" - it's easy to ignore ordering if you don't care about it, but it's a pain to reconstruct ordering if APIs decide to switch things around. (You'd have to put the order into attributes etc.)

From purely an XML validity point of view, it depends on the schema, if any, that describes what the rules are for formatting the XML.

That said, order must be preserved (see 2.1.1 in http://www.w3.org/TR/xml-infoset/) but whether it's "important" to an application is up to its author.

Within a schema, order can be made unimportant with the use of the xs:all compositor, though I'm not sure that this impacts the preservation of captured order, i.e. I'd still expect the order at origin/serialization to be maintained by XML processors.

However, in 1.0 this compositor adds a restriction on the child elements so that they must occur 0 or 1 times. In XSD 1.1, this restriction is removed, making it easier to contractually specify that order is not important, effectively xs:all has become the unordered version of xs:sequence.

Because of the overly-restrictive 1.0 xs:all compositor, the ordered xs:sequence compositor had to be used. Thus, order was often artificially imposed.

Adoption of 1.1 by vendors of validator libraries is slow.

As such, APIs need to consider order when being evolved with new elements. I am not aware of any XML serialization framework that can work with 1.1 and you have to assume your clients will be using 1.0 and will validate the 1.1 incoming messages with 1.0 rules and choke.

Luke

According to this article, the 1.0 version of the standard doesn't even require that parsers report siblings in the order they appear in the document. In that light, they would not be considered different, as both children are there. Perhaps this has changed, so that other answers are for newer versions of XML, though.

While XML attribute ordering is not significant as far as the XML standard is concerned, the textual representation of XML does by necessity place the attributes in a specific order. This can be an issue for things like XML Signature, which generates a digital signature for XML documents. A different attribute order would generate a different signature, which clearly is wrong.

For this (and other) reasons, there is now a standard for XML Canonicalization, which defines rules for re-organising XML documents such that they retain the same information content, but have things like whitespace, namespace declarations and attributes rearranged in a predictable way.

From xml.com

> Canonical XML requires the inclusion > of namespace declarations and > attributes in ascending lexicographic > order.

The XML 1.0 Spec does not say anything about the order of elements with equal names as children of the same parent element. So it seems, the issue is undefined.

However, most XML parsers and APIs will preserve the sequence as given in the textual representation. So, it is possible to implement applications that care about the element order. And the de facto answer to your question is: Yes, the order matters. The two examples are different.

Looking more closely, you'll need to eveluate what your use case is. If your XML needs to interoperate with different (maybe 3rd party) applications, you should always assume that order matters. If you have total control on the producing and consuming application, then you might relax this rule.

As always, you'll have to judge.

There is a difference. You can use various XML API's to process elements in sequence or find an element by index. Of course order may not matter in your particular example, but that depends on the semantics of the data.

The order is captured.

I think those should be considered identical, but it's really up to the software or person reading it to decide. XML is just a way of writing out data. The application determines how that data is used and therefore much of the meaning.

If your application reads in all of the person elements and then alphabetizes them by name, then the order in the XML document is meaningless. If your application reads them in and assigns seats in the same order the people appear in the XML, then the order is very important.

It's up to the application that uses the data. If the order is important, it should be described in the specs for people generating the files.

http://www.ibm.com/developerworks/xml/library/x-eleord.html

Maybe the discussion in the article will help to answer your question. Since your question is somewhat open, I am not sure if it covers you concerns.