Quoting m1duckett:

Quote:
NB: the original poster is wrong to expect the element order to change.

I am arguing the necessity of having the schema.

Quoting lmoelleb:

Quote:

Quoting lmoelleb:

2) Neither a DTD nor a Schema would nesessarely mean the order of the elements where fixed

Ambiguous data structures are poor programming practice.

Depends on what you mean with ambigious. If you refer to the lack of schema I agree (as you might recall, I specifically wrote regarding schemas: "a good idea to have one for sure"). If you refer to order of elements you are wrong as it simply isn't ambigious. Both the sort title and the "child root node" are child nodes of the same element. None of them means ANYTHING to the other, hence it would be completely arbitrary to define one of them has to come before the other. There is nothing ambigious about it.

Quote:

Quote:
However without the schema present you have to assume the worst as noone has promised you anything better, and the worst is elements in any order.

Any non-trival XML document will have semantic meaning to the structure of the data.  To make meaningful sense of random ordering, one would need to add an order of complexity to the implementation.  This would be a maintenance nightmare.

Both nodes are child nodes of the same element, that is all you can read out of the structure. Implementation is pretty simple, but you obviously needs to consider it when making the implementation. If using a SAX parser create the object, then add data to it as you go by - once you read the end node you know the object is complete and can process it (sure you need to consider it with large datasets not fitting in memory, but if you are skilled enough to deal with them in the first place, handling this should not be a problem). If you use a DOM it is even easier, as XPath does not really care about the order (unless you really force it to). No, this is not a maintenance nightmare.

Quote:

It is poor practice not to provide the data definitions to your clients.  DVD Profiler 2.4 provided an XML schema, I am not sure why one can not be provided for 3.0.  There certainly no trade secrets exposed by it.

This is obvious and I do not see anyone disagreeing with you, so no need going on about it.

Quoting m1duckett:

Quote:
Do you think processing

A.B.C.D

is the same as

A.D.C.B?

from a semantic point of view?

It depends on the context (which is obviously why schemas allows you define both sequences and choices). In the given context of this discussion we have node B and C, both being child nodes of A. Neither B or C has any specific meaning to each other (child profiles and sort title of the parent profile really has no relation besides belonging to the same parent profile). Hence the order of B and C is irrelevant, what is important is that both are child nodes of A.

Quote:

stylesheets break,

I am here making the assumption you are talking XSLT, as I have no other context than XML for the word "stylesheet". Both the apply-template and value-of commands work of XPath expressions and I can't even imagine how bad these expressions would have to be before the order mattered. I hope you do not base all your stylesheets on node iteration? 

Quote:

code breaks, etc...

I already told you how to code it the right way. It's not like it is any harder to program it the correct way - just stop trying to force old habbits of manual binary serialization into your code, and take full advantage of the various XML related tools.