5 ms·
The SLAX Scripting Language: An Alternate Syntax for XSLT
- ddowner 4mo agoSLAX 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!
- codeulike 4mo agoThe result is scripts that are easier to develop and maintain. I believe this goes against the official specification of XML
- pwagland 4mo agoAt the very least, it goes against the spirit of the specification, even if there is no explicit wording forbidding it.
- pitched 4mo agoSome 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#expressions https://juniper.github.io/libslax/slax-manual.html#expressio...
- bux93 4mo agoIn "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!
- phatskat 4mo ago[dead]
- petesergeant 4mo agoI 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.
- yxhuvud 4mo agoAlso, "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.
- Finnucane 4mo agoThat 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.
- nullorempty 4mo agoAny 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.
- Mesmoria 4mo agoConfirmed.
- deleted 4mo ago[deleted]
- mcv 4mo agoWhile 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.
- euroderf 4mo agoA quick visit revealed nary a single example.