What's wrong with XML?
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.
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.
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.
With XML you usually end up needing custom code to convert to and from the parsed XML representation and the language's built-in data types and structures.
This is less of a concern for statically typed languages where you usually have to marshal data to and from your own structs/classes whether it's XML or JSON.
ISO 8601, as used by XML Schema:
<foo>2020-09-04T00:00:00Z</foo>
or
Unix date output format (not sure this has an actual name)
<foo>Fri 04 Sep 2020 00:00:00 GMT</foo>
or
some sort of destructured date
<foo> <year>2020</year> <month>09</month> <day>04</day> <!-- ... --> </foo>
or
some sort of destructured date with 0 based months because Java
<foo> <year>2020</year> <month>08</month> <day>04</day> <!-- ... --> </foo>
Your app still needs to know what is coming in, and convert that to its internal format.
Even if you want to get everyone to agree on XML Schema's datetime format, it's not always sufficient because sometimes you need the actual time zone (e.g. America/New_York ) rather than the UTC offset especially when dealing with recurring/far off events.
The real advantage of JSON was (IMHO) that it didn't let you do _anything else_.
It's powerful enough to represent documents, which might be too much for data structures:
<a>This is <b>valid</b> XML</a>
<config>
<somekey type="string"><![CDATA[4byte emojii]]></somekey>
</config>Take an XML document. Validate it.
Take all of the top level elements. Call getElementByID on each with the same value. Combine all the answers into an array, eliminating the nulls.
You might expect that array to have length one or zero on all valid documents. You’d be wrong, and dangerously so for some XML schemas. You can use the same ID on every node and I don’t know of a parser that would balk at that. And yet every implementation will return the first node that has that ID, which will then change any time you descend into the DOM.
And here lies the main problem of XML. As a technology, it is better than its reputation. Sadly, next to no one knows how to use it properly.
Too bad it was initially envisioned as a text markup language, with tags sparsely strewn around the text, and not as a data representation format.
So, the syntax ended up both overly cumbersome (see closing tags) and festooned with logically unnecessary shorthands like node attributes. Then, the terror of entities.
XSLT is a brilliant language, I'd say the first pure functional language widely used outside academia (in 2000s), but, based on XML syntax, it's completely unfit for human consumption.
If only the authors of XML could get rid of the shackles of SGML compatibility, and went with a simple, uniform syntax, e.g. s-expressions, we could still be gladly using it. Now we reinvent the ecosystem instead, with JSON (sigh) and YAML.
Of course if you use only one limited tool which was never meant to be the main manipulator of xml (getElementByID), then you'll run into problems. It is like never using regexp and complaining that simple strings are a bad data structure.