> My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections.
Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental difference if they were never part of the spec and you had to use sub-elements to define such properties, except perhaps for the fact an attribute of a given name can only be declared be once (which an interesting difference between JSON and XML - XML lacks any syntax for declaring arrays, so you must be able to declare multiple sub-elements with the same name).
as can be seen to the comments to to my comment, there are quite a number of ideas on the ontology of the XML format. when a single screen worth of text on my phone can hold at least 3 strong convictions on how to use a format, then it is doomed to fail.
Just as an anecdote: about two years ago I had a discussion about marshalling data structures into XML and indeed, two people managed to come up with three different schemes [0]. Of course that spells doom for something that's supposed to be used as a data-exchange format.
Can't say I've ever thought of it that way - attributes just seemed like a simpler syntax for the common case of basic properties that were sensibly represented as strings (i.e. single, literal values). I don't think it would have made much fundamental difference if they were never part of the spec and you had to use sub-elements to define such properties, except perhaps for the fact an attribute of a given name can only be declared be once (which an interesting difference between JSON and XML - XML lacks any syntax for declaring arrays, so you must be able to declare multiple sub-elements with the same name).