<cds>
<cd><title>Led Zeppelin II</title><artist>Led Zeppelin</artist><price>999</price></cd>
<cd><title>La Brise<title><artist>Arax</artist><price>999</price></cd>
</cds>
or <cds>
<cd>
<title>Led Zeppelin II</title>
<artist>Led Zeppelin</artist>
<price>999</price>
</cd>
<cd>
<title>La Brise<title>
<artist>Arax</artist>
<price>999</price>
</cd>
</cds>
vs something like [
{"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},
{"title": "La Brise", "artist": "Arax", "price": 999},
]
You can probably do better using XML attributes. But then you're using more features.Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in ways that is frustrating.
If you absolutely don't care about human interface, no reason to use XML either. It's meant to be more verbose. The XML tags will often dominate the size of the payload with things like `<question>Who</question>`, so you have to start thinking about shorter names. Yes JSON has a similar problem, but at least it's halved and you don't have to instruct everyone to call each list element "e". If you super care about size, you'll use protobufs or something.
something like duplicating info in closing tags in XML (which applies to every element) isn't really comparable to stuff like having to escape certain characters in JSON strings (which applies only to the values use those things)
perfect is the enemy of the good, and the good is the metric
As for "looks horrible"... well yeah, I always feel that xml looks "spikey" somehow. But I've been programming in curly-brace languages for 30+ years and I still find json harder to read than xml: I think my brain tries to interpret it as code, not data. I find xml easier to read (even when its unformatted) precisely because the close-tokens kind of document what element they're closing.
Each to their own I guess. At least we're not stuck using ASN1.
Prepare for trouble, and make it double: http://xml.coverpages.org/dstc-xer2.html