Here here. I would describe it something like: XML is great as a document format, but shitty as an RPC format. JSON is vice-versa. Web developers spend a lot of time with JSON as an RPC format, so they tend to put it on a pedestal. But try keeping your recipe collection structured in JSON text files and the pain will start immediately. YAML is even worse.

XSLT was (and still is) great for transforming documents. Want that recipe collection as HTML? Easy.

Yep:

- If you are describing hierarchal data, JSON is great

- If you are describing text with markup, especially extensible markup, for machine generation and consumption, XML is great.

- If you are describing a graph, neither have broadly accepted standards so you are kinda on your own.

Depending on your requirements, a recipe collection might be better in XML or in a flavor of markdown. A comprehensive data schema and software support for recipes could be challenging/limiting, compared to marked-up text.

> If you are describing a graph, neither have broadly accepted standards so you are kinda on your own

Relational databases can describe most graphs, but they rarely ever have a great text format.

And CSV for tabular data!

If only it was more standardized :-(

Markdown (like HTML) offers formatting structure, not semantic structure. Maybe you want to query for recipes that can be made in under an hour, or that contain orange as an ingredient (as opposed to merely a serving suggestion in an orange bowl). A proper XML (or even JSON or YAML) structure would enable this, Markdown does not.

You can pretty easily translate XML to Markdown using XSLT, though.

I don't think hierarchal structure is the differentiator; recipes and web pages are hierarchical and they'd still be hell in JSON. XML handles hierarchy just fine. I think the differentiator is whether your content is a document, that is, composed significantly of multiline text. Multiline text in a JSON file tends to be human-hostile, but we're all comfortable editing eg html.

JavaScript is as good as JSON. It has eaten The world jest because it was in every browser. Similarly Chrome, advertised on the biggest search engine.

I first touched XSLT in 2010. I appreciated what it could do, but it was painful to work with due to poor documentation and tooling. This has only gotten worse by comparison with alternatives.

You can still do XSLT in the browser. You can serve arbitrary XML and transform it. As an example, Atom feeds on my website (such as <https://chrismorgan.info/blog/tags/meta/feed.xml>) render just fine in all mainstream browsers, thanks to this processing instruction at the start of the file:

  <?xml-stylesheet type="text/xsl" href="/atom.xsl"?>

But working with it is not particularly fun, because XML support in browsers has been only minimally maintained for the last twenty or so years. Error handling is atrocious (e.g. largely not giving you any stack trace or equivalent, or emitting errors only to stdout), documentation is lousy, some features you’d have expected from what the specs say are simply unsupported (and not consistently across engines), and there are behavioural bugs all over the place, e.g. in Firefox loading any of my feeds that also fetch resources from other origins will occasionally just hang, and you’ll have to reload the page to get it to render; and if you reload the page, you’ll have to close and reopen the dev tools for them to continue working.

I think out of the box, browsers can only do xslt 1; but Saxon offers a JS version of their engine that does xslt 3.0 and is free (as in beer): https://www.saxonica.com/saxon-js/index.xml

It’s actually worse than XSLT 1.0 due to inconsistencies and incompletenesses. For example, Firefox doesn’t respect <xsl:output method="html">, but uses an XML parser on the transformed result regardless; and doesn’t support disable-output-escaping. I wanted these for my Atom stylesheet (for <content type="html"> and the likes; instead I had to emit serialised HTML and decode it in JavaScript, though with difficulty I could have done feature-detection to skip that step if disable-output-escaping worked).

Even perfunctory probing shows fairly serious problems in Firefox (where Chromium is consistently much better, in this specific area). I could file quite a few bugs in short order (e.g. these mentioned, bad document.contentType values, <template> not working properly), but I don’t think there’s any interest in fixing things.

(I wrote this comment as much for my own future reference as anything else. XML/HTML polyglot stuff makes things decidedly messy at times.)

> In JSON you can't get to the parent from the child. And walking down a tree is unintuitive, because nodes can be of different types

JSON only competes with XML. XSLT, XPath, and XSD are just as much an afterthought in that they are completely separate from XML and are entirely optional. The engines written around those is where the powers to walk the tree and validate come from, not XML itself. There's a wide range of tools to get the same benefits for JSON sources, and they usually handle XML and other data sources too, because it shouldn't matter. The reason the X* tools have fallen out of favor is because they're unnecessarily tied to a single type of source data.