There are many widely used data formats, such as OpenDocument files, that are XML underneath, often packaged up as .zip files. Much engineering data, such as KiCAD printed circuit board layout info, is in XML. COLLADA, for 3D animation and robotics, is XML. Open Street Map is XML. If you need to represent a large, complex tree-structured data object portably, XML is still usually the way to go.

I agree that it's a decent approach for that extremely narrow use case.

My point is the extent to which that is different from the peak of XML's hype cycle, which was circa 2000. Then, XML was everywhere. E.g., eBay circa 2004 would render data internally as XML, which would get passed off to multiple Rube Goldbergian XSLT transformation layers on its way to becoming HTML. Or I did some work at a bank around then, and their internal architecture was very XML-heavy. There was no good reason for this, and from what I see JSON now dominates.

I note though that your examples were all created when XML's hype cycle was in full swing, and many have enterprise roots. I'll be interested to see if projects created today end up using XML even for the document-creation cases for which it was intended. JSON is also a way to represent large tree-structured data, and I wouldn't be shocked to see it take over most of the data sharing just because that's what everybody knows.

JSON tools tend not to scale. See [1] A 1MB JSON file will blow up some tools. Engineering models of real-world objects are much larger than that. There's sort of an assumption with JSON that you'll read it into a JSON tree and work on that, not process it sequentially.

[1] https://news.ycombinator.com/item?id=12063626

I'm willing to believe that's currently true, but that doesn't strike me as much of a moat for XML.