4 ms·

Im sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have <point><x>4</x><y>5

Im sure there are better answers here but my main issue is that attributes and child elements offer duplicate functionality. You could have <point><x>4</x><y>5</y></point> or you could have <point x=4 y=5 />. There is often no consistency within a single spec over how this should be done let alone between different specs. JSON feels much more logical to me as well as being a whole lot simpler. If only it supported comments.

shmerl 6y ago
Yeah, I agree. Though I usually view elements as data and attributes as metadata, but in practice the usage is all over the place.
- agumonkey 6y ago
  Or it results in neverending discussions about when to do what and why it's somehow better
andyjohnson0 6y ago
The functionality isn't quite duplicated. Attributes are order-independent and can't have child attributes, for example. As far as I know, the original intention of the language designers was that attributes are for metadata and sub-elements are for data. For non-trivial schemas that form part of a data contract between systems or organisations, and/or are expected to evolve over time, I tend to stick to this approach. It results in more verbose data, but in my experience thats almost never a problem and can be an advantage if I have to drop into the data and actually read it. For smaller-scale and internal schemas (e.g. internal tool configs) the terseness of e.g. <add key="foo" value="bar"/> definitely wins out over design purity for me. JSON would be equally good for this. I work on enterprise integration and messaging stuff and I deal with a lot of XML data every day. JSON has its uses (particularly when you control both ends of the serialisation pipeline) but for me XML has a lot of advantages.
tonyedgecombe 6y ago
I always assumed attributes unless I was dealing with a composite or enumerable type. Of course if someone else is producing the data then they can make a mess of things but I don't think that is specific to XML.

shmerl 6y ago

Yeah, I agree. Though I usually view elements as data and attributes as metadata, but in practice the usage is all over the place.

agumonkey 6y ago
Or it results in neverending discussions about when to do what and why it's somehow better

andyjohnson0 6y ago

The functionality isn't quite duplicated. Attributes are order-independent and can't have child attributes, for example. As far as I know, the original intention of the language designers was that attributes are for metadata and sub-elements are for data. For non-trivial schemas that form part of a data contract between systems or organisations, and/or are expected to evolve over time, I tend to stick to this approach. It results in more verbose data, but in my experience thats almost never a problem and can be an advantage if I have to drop into the data and actually read it. For smaller-scale and internal schemas (e.g. internal tool configs) the terseness of e.g. <add key="foo" value="bar"/> definitely wins out over design purity for me. JSON would be equally good for this. I work on enterprise integration and messaging stuff and I deal with a lot of XML data every day. JSON has its uses (particularly when you control both ends of the serialisation pipeline) but for me XML has a lot of advantages.

tonyedgecombe 6y ago

I always assumed attributes unless I was dealing with a composite or enumerable type. Of course if someone else is producing the data then they can make a mess of things but I don't think that is specific to XML.