Comment by eftpotrm
For who though?
If you're a user of whatever-data-format designing your new application, you could always use the subset you actually cared about. No-one forced you to use all the complex bits in XML.
If you're a library author - well, yes, you could implement a Json parser at first that was eval(input), then something more complex because that's a security hole, then something else again because that's not too quick, then a new library like JsonPath to get queryability, and... all your work is still less functional than the system you were trying to replace. So yes, you can possibly implement Json libraries in less code than implementing XML libraries. But unless you had a reason to implement a new XML library from scratch anyway, that isn't actually a win.
> No-one forced you to use all the complex bits in XML.
Just parsing XML alone is hugely painful, let alone implementing the rest of the stuff like XSLT, namespaces, validation, xpath, etc etc. Plus, once you've done this, you still need a natural way to map this into domain types, or you need to force people into a visitor pattern or some other awkward deserialization technique. JSON just requires a single JSONValue sum type.
XML has its place, but it'd have to be a pretty extreme case of needing rigor or a tree where I need to be able to peg arbitrary attributes onto the nodes in order to see it as attractive. Most APIs won't benefit from all of XML's features.
For instance I maintain a podcasting/rss feed library and XML (And more importantly, the way people publish invalid xml) makes me really wish they had gone with a different format in the day that was harder to fuck up.