Does XML care about the order of elements?

XML confuses me sometimes, but I'm trying to get this figured out. What the vendor is telling me doesn't make sense but again, XML and I don't get along :)

I have some XML that I'm sending to a vendor's web service that is giving me random failures:

<root>
    <Request>
        <Driver id="1" VehId="1">...</Driver>
        <Driver id="2" VehId="1">...</Driver>
        <Driver id="3" VehId="2">...</Driver>
        <Vehicle id="1">...</Vehicle>
        <Vehicle id="2">...</Vehicle>
        <Driver id="4" VehId="2">...</Driver>
    </Request>
</root>

There is no XSLT or XSD to compare against to see if my XML is valid.

The vendor states that the XML is invalid because Driver #4 is in the wrong area. The XPath for Driver should be root/Request/Driver and Vehicle is root/Request/Vehicle.

Is it common that XML parsers would force an element order, especially if there is no XSD to compare the XML to? The vendor's support is slow to get back with me, so I want to know what good common practice is.

Followup

I complained enough to our account rep about not being able to test this (and made it sound like they were just trying to get support money) that it turns out that the Developers have the XSD, but Support doesn't. So I had been talking to the wrong group *facepalm*

I got the XSD, and it does enforce a specific order of elements.

Now to fight them in regards to their own sample XML doesn't follow the schema, but at least now I have something to test against.

#XML schema compositor "sequence" will enforce ordering I know this is old but I just came upon the post.

Until today I would most likely answer the question Does XML care about the order of elements? with No, unless you use a poorly written xml parser.

However, today a third party application complained that the xml files I created were invalid. They use an XSD file to validate the xml. And yes, you can enforce the order or elements within an xsd file:

<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:complexType name="ComplexType">
    <xs:sequence>
      <xs:element minOccurs="0" maxOccurs="1" default="" name="Value1" type="xs:string" />
      <xs:element minOccurs="0" maxOccurs="1" default="" name="Value2" type="xs:string" />
    </xs:sequence>
  </xs:complexType>
</xs:schema>

The keyword is xs:sequence

> The sequence element specifies that the child elements must appear in > a sequence. Each child element can occur from 0 to any number of > times.

which is in contrast to xs:all which does not care about the order but only allows elements which occur zero or once.

> Specifies that the child elements can appear in any order. Each child element can occur 0 or 1 time

(The words sequence and all are both what is called a Compositor in the XML Schema definition.)

If there is no XSD (XML schema) at hand, then all you can check for is whether or not your XML is well formed.

In your case - it is. There are no overlapping XML tags, no XML tag that are left open or anything of that sort.

If the vendor needs to enforce things like order inside the XML, he ought to provide an XSD file - otherwise, his "requirements" cannot be validated and checked....

Vendors will do what they will do, but it is a nonstandard application of XML to rely on ordering.

XML is declarative, not procedural. So, it shouldn't be "stepwise".

XML schemas can enforce element order. If there's no schema, neither order nor tags nor general structure not the kind of text (if it's a number or anything) is prescribed in any way - in theory. Of course that's not the case here.

It is perfectly possible to parse* data from XML without caring about order, but it can be easier (e.g. when using SAX, I imagine, or when you're a lazy bastard writing very sloppy code) to parse if you assume a certain order. Although they should include some schema if they want a certain order, it's perfectly possible that their parser chokes on it anyway. Yes, they shouldn't do this, but obviously they don't care.

*By "parsing" I don't mean "take that XML document and turn it into e.g. a DOM", but "take that e.g. DOM and extract the information from it".

Accessing XML by DOM preserves the order of nodes the way they are in your XML document. Look here:

http://www.w3schools.com/dom/dom_nodes_nodelist.asp

there you find:

> A node list object represents a list > of nodes, in the same order as in the > XML.

If your web service is relying on the order is a different question - it may or may not, that depends on the web service implementation.

An XML schema may or may not enforce element order. It depends on the schema in question. In the most general sense, XML element order does not matter, unless otherwise specified by the appropriate schema.

Well I think the best possible answer is - ask them. They could even be parsing your XML as a text file and so you might need to have line breaks and some "correct" order of attributes.

If they would parse this correctly order wouldn't matter (at least not in terms of valid requests). As I see it they should build two tables and join them with supplied ids.