XML Element Ordering

xml-element-order.md

XML Element Ordering

TL;DR

If your XSD is using the xs:sequence indicator, then the order of the elements in that complex type matters, and they should be included in the order listed inside the tag.

XML Specification

Generally speaking, the order in which child elements appear inside their parent element container in XML shouldn't matter. As such, the following two examples would be considered semantically equivalent XML.

<parentElement>
	<childElement1>1</childElement1>
	<childElement2>2</childElement2>
	<childElement3>3</childElement3>
</parentElement>

<parentElement>
	<childElement2>2</childElement2>
	<childElement3>3</childElement3>
	<childElement1>1</childElement1>
</parentElement>

While it is true that the set of rules defined by the XML specification would consider both of these to be well formed XML, whether or not these two examples would be considered valid - let alone equivalent - actually depends on the XML schema in use.

XML Schema Languages

An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic constraints imposed by XML itself. While there are numerous types of these languages, arguably the most popular of them is the W3C recommended XML Scheme Definition (XSD). Others include Document Type Definition (DTD), Relax NG and Schematron.

XML Scheme Definition (XSD)

Like all XML schema languages, XSD can be used to express a set of rules to which an XML document must conform in order to be considered "valid" according to that schema. However, unlike most other schema languages, XSD was also designed with the intent that determination of a document's validity would produce a collection of information adhering to specific data types. Such a post-validation infoset can be useful in the development of XML document processing software. - Wikipedia

When defining your schema with XSD, you can specify whether or not order matters.

When Order Matters

When you use the xs:sequence indicator, you are saying that the order of the elements matters, and it should follow the order specified.

<xs:element name="compElement">
	<xs:complexType>
		<xs:sequence>
			<xs:element name="ele1" type="xs:string"/>
			<xs:element name="ele2" type="xs:string"/>
			<xs:element name="ele3" type="xs:string"/>
			<xs:element name="ele4" type="xs:string"/>
		</xs:sequence>
	</xs:complexType>
</xs:element>

Fro XSD 1.0 implementations, this also means that each child element can occur from 0 to any number of times (unbounded).

When Order Doesn't Matter

When you use the xs:all indicator, you are saying that the order of the elements does not matter.

<xs:element name="compElement">
	<xs:complexType>
		<xs:all>
			<xs:element name="ele1" type="xs:string"/>
			<xs:element name="ele2" type="xs:string"/>
			<xs:element name="ele3" type="xs:string"/>
			<xs:element name="ele4" type="xs:string"/>
		</xs:all>
	</xs:complexType>
</xs:element>

For XSD 1.0 implementations, this also means that each child element can occur from 0 to 1 time.

But, Why?

The use of XSD for structure definition makes order more likely to be a requirement. That's because XSD has richer support for ordered lists (xs:sequence) that for unordered lists (xs:all). Unordered lists have occurrence restrictions - as noted above - are more difficult to validate and are not extensible in the way ordered lists are. Some of that is improved in XML Schema 1.1, but not all tools or API - especially older ones - have support for this version of the specification.

Additionally, objects whose property setters have side effects can fail if the properties aren't set in the right order. For example, a class with a private Person field that exposes PersonID and Name properties. The PersonID setter creates the private instance of Person, and the Name setter sets the Name property on the private Person field. In this case, setting Name before you set PersonID fails, because Person doesn't exist yet. In this case, implementing a schema that requires PersonID to appear before Name in the XML keeps this error from happening, at the cost of forcing other developers to do things that appear nonsensical. This is not considered good design.

Hi Scott, Thank you for share your knowledge, but I have a question, I have a file XML using XSD and the elements in the response come in disorder, what should it be the reason?

    <xsd:complexType name="compElement">
        <xsd:sequence>
            <xsd:element name="ele1" type="xsd:int"></xsd:element>
            <xsd:element name="ele2" type="xsd:int"></xsd:element>
            <xsd:element name="ele3" type="xsd:int"></xsd:element>
            <xsd:element name="ele4" type="xsd:int"></xsd:element>
            <xsd:element name="ele5" type="xsd:string"></xsd:element>
        </xsd:sequence>
   </xsd:complexType>

   Response
  <compElement>
    <ele1>3</ele1>
    <ele3>2600</ele3>
    <ele4>250</ele4>
    <ele2>90</ele2>
    <ele5>String 2600</ele5>
  </compElement>

Thanks

I find the XSD constrained support for unordered lists (xs:all) to be short-sighted, specifically that I cannot specify maxOccurs greater than 1 in an unordered list. Upgrading to XML Schema 1.1 is not an option for our large application, and we generate classes using JAXB from the schema so it is required to specify unbounded for lists.
In our schemas the dependencies between attributes is always handled using a complex type, so we would not have the side effects if the properties are not in the right order.