[j45]

Universal love is one factor, best tool for a job may leave only a few choices including XML.

It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be.

XSLT might just need a higher abstraction level on top of it?

[larodi]

Perhaps it rather needs a facelift and support for JSON. I would imagine one day something regex or jq-level concise emerges, something reasonably short and descriptive, to allow transforming arbitrary tree into another arbitrary tree.

The idea behind XSLT is genial, but the real essence of it is XPath which makes it possible. And we've seen XPath evolve into CSS Selectors, and being useful on its own.

So in essence there are two sides of the transformation:

  - selection - when you designate which parts of the tree match
  - transformation - when building the new three

And while there are established approaches to the first part, perhaps XSLT is the only one which fits the definition of 'generally accepted' when it comes to the transformation.

But one can argue the transformation is possible with jq, it is just that I definitely don't like its overly-engineered syntax. IMHO the champion of the transformation syntax is yet undecided, even though in 2025 XSLT is still more or less king. Which is fascinating as XML is long not a usual choice of preference.

[masklinn]

If XPath was the core nobody would need xslt, because pretty much every xml library can do XPath.

Don’t get me wrong, XPath is by far the best thing to come out of the xml ecosystem, but the actual idea at the core of xslt is the match/patch during traversal, and talking about it in terms of selection misses that boat entirely. Select / update is how you manipulate a tree with jQuery, or really the average xml library.

[j45]

I recall seeing some libraries on github that convert back and forth between xslt and json... and another short hand version that was much clearer from Juniper I believe.