XML gets a lot of flack, and I think part of it is that "enterprise" solutions have mis-used and abused it so much (and part of it might be that people started out with only DTDs for specifying schemas).
Today, I think it's obvious that xml shouldn't ever really be written by a human, it should be used for machine generated interchange of data, much as html -- markdown and rst are reasonable languages to write in -- html "requires" a gui/wysiwig editor -- just as it really isn't pleasant to work with eg: xml config files directly. Or ant-scripts. It just isn't. Yes, you can hide the ugly with a smart editor, but it's still pretty ugly.
Now, html might be pleasant compared to writing in Postscript -- but it's not really pleasant to write (hence things like sparkup).
I believe the issue that many people have with XML goes a bit deeper ... using XML means you are creating a bit of distance between yourself and the host programming language. XML stands alone, apart, that distance comes with costs in terms of ease of use (which could have been addressed by proper tooling), as well as many benefits.
HTML may not be pleasant to write documents with and I would say exactly the same thing of json ... show me the equiv of a Word document in json and I would argue that only a madman would like to directly edit that.
Really, James Clark said it right, 'json for data, xml for documents'.
Today's 'ease of use' of manipulating a native data structure of the 'language du jour' will eventually be viewed a bit more negatively in the years, decades to come. But really this is a storm in a tea cup ... XML has embraced json and has lots of support for generating it so I am fine. For others, they will eventually find the boundaries of json and start redeveloping the same concepts.
However, all the above being said/done I do think json is the right 'over the wire' format for data today; I just think we should embrace heterogeneity instead of 'knee jerk' cargo cult advice of 'don't use XML'; that's the equivalent of throwing tools out of one's toolshed and that's just plain stupid.
The strength of xml is xsl. The ability to declaratively transform the content into another form. I'm not aware of any way to do this with json other than by hand-rolling code.
I would say that the strength of XML is XPath - forget the rest of XSL (XSLT and XSL-FO) - and I would still avoid it unless there was a real requirement for "document like" content.
I'm not entirely certain that is a plus... Is writing a compiler/translator in xsl really more pleasant/easier to maintain than writing it in a "proper" language?
Today, I think it's obvious that xml shouldn't ever really be written by a human, it should be used for machine generated interchange of data, much as html -- markdown and rst are reasonable languages to write in -- html "requires" a gui/wysiwig editor -- just as it really isn't pleasant to work with eg: xml config files directly. Or ant-scripts. It just isn't. Yes, you can hide the ugly with a smart editor, but it's still pretty ugly.
Now, html might be pleasant compared to writing in Postscript -- but it's not really pleasant to write (hence things like sparkup).