Why do people accept XSD requiring elements in a particular order?

In a recent task 开发者_运维技巧at work, I've been building the PHP end (using SimpleXMLElement) of an XML interaction with a .NET app. I've been encountering differences in conceptual thinking with my counterparts in .NET land, specifically because they're just using the XSD/XML libraries in .NET without thinking much about that, whilst I'm finding myself having to bend over backwards because of XSD's limitations. In other words, I couldn't understand why their XML ingestor falls over if I give elements in the 'wrong' order or has ones it doesn't know about, and they don't understand why I care. (Instead my opinion of their development practices is lowered because they don't want to care.)

Is blind acceptance of XSD generation the real culprit here? Why do people accept it being so fussy?

XSD doesn't require elements to be in a particular order, it just allows you to insist that elements be in a particular order.

One thing that's nice about forcing elements to be in a particular order is that, if you are actually hand-editing XML, the intellisense will automatically assume you want the next tag in the particular order. If you just use xs:all instead of xs:sequence, the intellisense will list all the possible next elements, and you will have to choose which one (or get to choose, depending on your perspective :)).

I would also add that, using a fixed order makes the XML files more user friendly to work with. True, it should make no difference to the software reading in the file whether you order your coordinates x, y, z or z, y, x, but a human reading these coordinates would have an easier time if the order follows common convention. It's also easier for a human to compare two XML files to see what's different about them if everything is in the same order.

Just to turn the question on its head, What is the disadvantage of using a fixed order? :)

It makes sense to require elements in a certain order. That way you know where the data's supposed to be. And when you're comparing XML data visually, everything matches up. Order > chaos, IMHO. It's like XSD is doing it's best to fight against Newton's 2nd law.

But you can use an xs:all element, so that order doesn't matter.

There are several reasons why is xs:sequence by default:

1. Control over elements appeared with in element. So you can without tricks say that Name element should appear exactly one. Address could appear 3 times. And Telephone is optional.
2. Fast processing. You can process element over the element. Without sequence reading logic will be more tricky.

This is apart of human writability.

There are processes that can't function properly if their input doesn't arrive in a specific order. To pick a somewhat simplified example, it's easy to envision a process that uses XML like this:

<Transaction>
   <AuthenticationCredentials>...
   <Operation>...
</Transaction>

If that process is reading from a serial stream, and it needs to authenticate the sender before performing the operation, then it needs those two elements to arrive in that order. Having a schema that enforces this, and distributing it to senders, eliminates an entire class of errors from the process.

At any rate, it's not at all clear from what you've posted that you're bending over backwards "because of XSD's limitations." The limitations are, most likely, in the system that's using the XML, not in the schema that validates its messages. There may be completely valid reasons for those limitations to exist.