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.
In "peeking under the hood", it says quite honestly "SLAX is purely syntactic sugar."
I think that the XML syntax of XSLT itself was only one barrier for people to adopt XSLT, even in the XML heydays.
The main obstacles appear to me that the execution model is hard for people to graps; you need to think both as a parser (apply-templates/) and in a more declarative style at the same time. The XSLT can be in a completely different order to the document and in fact it can visit nodes in the document multiple times, hopping through nodes in a different order each time, with lovely constructs like apply-template with "mode" and "select" mixed with call-template by "name", plus you get to use xpath and for-each to boot. The control flow changes from the order in the input, to some predefined order, and back depending on when you decide to match(-template) or for-each. There's a lot going on at the same time! Fun times!
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.
Also, "Built on top of libxslt and libxml2" is a fairly harsh restriction in that it stops any usage of xslt 2.x or 3.x. Which has quite significant improvements.
That was my impression also. Anyone working with complex xml documents is going to want xslt/xpath 2 and 3 and probably xquery as well. This isn't going to offer any improvement over that.
The result is scripts that are easier to develop and maintain.
I believe this goes against the official specification of XML
At the very least, it goes against the spirit of the specification, even if there is no explicit wording forbidding it.
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.
Confirmed.
Some examples of where it improves XSLT would be helpful. The first one I found in the docs looks roughly identical: https://juniper.github.io/libslax/slax-manual.html#expressio...
In "peeking under the hood", it says quite honestly "SLAX is purely syntactic sugar."
I think that the XML syntax of XSLT itself was only one barrier for people to adopt XSLT, even in the XML heydays.
The main obstacles appear to me that the execution model is hard for people to graps; you need to think both as a parser (apply-templates/) and in a more declarative style at the same time. The XSLT can be in a completely different order to the document and in fact it can visit nodes in the document multiple times, hopping through nodes in a different order each time, with lovely constructs like apply-template with "mode" and "select" mixed with call-template by "name", plus you get to use xpath and for-each to boot. The control flow changes from the order in the input, to some predefined order, and back depending on when you decide to match(-template) or for-each. There's a lot going on at the same time! Fun times!
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.
Also, "Built on top of libxslt and libxml2" is a fairly harsh restriction in that it stops any usage of xslt 2.x or 3.x. Which has quite significant improvements.
That was my impression also. Anyone working with complex xml documents is going to want xslt/xpath 2 and 3 and probably xquery as well. This isn't going to offer any improvement over that.