Consider the following example:
<MyRoot>
<AnElement type="list" items="1">
<Item>Hello, World!</Item>
</AnElement>
<MyRoot>
Most parsers have type aware parsing, so that if somebody tucks string to a place where you expect integer, you can get an error or nil or "0" depending on your choice.JSON for all it's flaws is beautifully simple in comparison. A number is either a number or the document is invalid. Arrays are just arrays and objects are just objects.
XML on the other hand is the wild west. This particular XML beast had some difficulty sticking to one thing.
Take for instance lists. The same document had two different ways to do them:
<Thing>
<Name>...</Name>
<Image>...</Image>
<Image>...</Image>
</Thing>
<Thing>
<Name>...</Name>
<Images>
<Image>...</Image>
<Image>...</Image>
</Images>
</Thing>
Various values were scattered between attributes and child elements with no rhyme or reason.To prevent code reuse, some element names were namespaced, so you might have <ThingName /> and <FooName />.
To round off my already awful day, some numbers were formatted with thousands separators. Of course, these can change depending on your geographical location.
Now, one could say that this is just the fault of the specific XML files I was parsing. And while I would partially agree, the fact that a format makes this possible is a sign of it's quality.
Since there's no clear distinction between objects and arrays you have to pick one. Or multiple.
Since objects can be represented with both attributes and children you have to pick one. Or both.
Since there are no numbers in XML, you can just write them out any way you want. Multiple ways is of course preferable.
I know you describe a real-life situation, but if XML gets abused it's not XML's fault - like it's not JSON's fault if JSON gets abused
As far as I can tell, the file was a fully valid XML file. The issue is that doesn't really tell you (or guarantee) much.
There's just no one specific way to do a thing.