There exists a peculiar amnesia in software engineering regarding XML. Mention it in most circles and you will receive knowing smiles, dismissive waves, the sort of patronizing acknowledgment reserved for technologies deemed passé. “Oh, XML,” they say, as if the very syllables carry the weight of obsolescence. “We use JSON now. Much cleaner.”
https://www.w3.org/TR/2004/REC-xml-infoset-20040204/
Does this not cover it?
Do you mean if you were to follow XML standard but not XML information set standard?
Information set isn’t a description of XML documents, but a description of what you have that you can write to XML, or what you’d get when you parse XML.
This is the key part from the document you linked
This is also a great example of the complexity of the XML specifications. Most people do not fully understand them, which is a negative aspect for a tool.
As an aside, you can have an enforced order in XML, but you have to also use XSD so you can specify xsd:sequence, which adds complexity and precludes ordered arrays in arbitrary documents.
If the XML parser parses into an ordered representation (the XML information set), isn’t it then the deserializer’s choice how they map that to the programming language/type system they are deserializing to? So in a system with ordered arrays it would likely map to those?
If XML can be written in an ordered way, and the parsed XML information set has ordered children for those, I still don’t see where order gets lost or is impossible [to guarantee] in XML.
You are correct that it is the deserializer’s choice. You are incorrect when you imply that it is a good idea to rely on behavior that isn’t enforced in the spec. A lot of people have been surprised when that assumption turns out to be wrong.