8 comments

[ 269 ms ] story [ 393 ms ] thread
The result is scripts that are easier to develop and maintain.

I believe this goes against the official specification of XML

I don’t hate this, but it’s fundamentally exactly the same language with a terser syntax. Once you’ve drunk the XSLT kool-aid you’re deep into an IDE that knows how to write it, with auxiliary tooling that knows how to process it, so I’m not sure what actual problem this would solve in the trenches.
Any incremental improvement and simplification had higher value in the past. Nowadays, the improvements need to be grandeur to justify introducing another way to achieve the same thing. I expect that LLMs will be great at writing standard XSL.
(comment deleted)
SLAX has small shoes to fill - XSLT is the data transform language no one asked for and no one needs. With a bar that low, the sky's the limit!
While more readable code is certainly nice, this article ignores the major advantage of XSLT being XML: you can use XSLT to generate XSLT.

And while that sounds like just a funny gimmick, it has real practical applications:

If you've got a CMS that generates HTML from XML documents, you can write the XSLT for that by hand of course. But if there are common patterns that most sites use (menus, for example), while different customers use their own custom document format, it would be really nice if you could generate that XSLT from the data model definition. Long ago I've worked on a CMS that did exactly that.

A quick visit revealed nary a single example.