5 ms·

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon def

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect. When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

sam_lowry_ 1y ago
Keys were a thing in XSLT 1.x already. XSLT 2+ was more about side effects. I never really grokked later XSLT and XPath standards though. XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous. Newer standards lost elegance and kept the ugly syntax. No wonder they lost mindshare.
- jerf 1y ago
  "Newer standards lost elegance and kept the ugly syntax." My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language. When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that I really don't like. And I speak Haskell, so the critic reaching for the reply button can take a pass on the "Oh you must not like functional programming" routine... no, Haskell is included in that set of "literally any other general purpose programming language" above.
  - yoz 1y ago
    Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new? There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades. [1] https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...
    - jerf 1y ago
      It would at least be an interesting project. If someone put the elbow grease into it it is distinctly possible that an XSLT stylesheet could be not just converted to JS (which is obviously true and just a matter of effort), but converted to something that is at least on the edge of human usable and editable, and some light refactoring away from being decent code.
    - bokchoi 1y ago
      I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro
      - sam_lowry_ 1y ago
        SLAX is great, unfortunately it was released a bit too late. XML world is full of ugly standards and failed contenders. None remembers RelaxNG. But had reacher expressive power than XMLSchema and a human-readable syntax.
        bokchoi 1y ago
        Schematron!
  - smrtinsert 1y ago
    Pretty true. I created a simplified XPath layer to a stax parser back in the day and it was a break through in xml usability.
- bokchoi 1y ago
  I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro It looks like it was developed by Juniper and has shipped in their routers?
thechao 1y ago
Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.
- badmintonbaseba 1y ago
  I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.
  - dolmen 1y ago
    libxslt, despites being available widely, must not be recommended. https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/ https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/
- jraph 1y ago
  - Browsers are XSLT (1.0) processors. - Xee: https://github.com/Paligo/xee https://github.com/Paligo/xee - xrust: https://docs.rs/xrust/latest/xrust/xslt/ https://docs.rs/xrust/latest/xrust/xslt/ - XJSLT (compiles XSLT to JS): https://github.com/egh/xjslt https://github.com/egh/xjslt Xee is WIP AFAIK and I don't know the maturity of xrust and XJSLT.
  - thechao 1y ago
    Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well! Also, I want a cookie & a pony.
    - jraph 1y ago
      I guess Xee is the most promising option then :-) But indeed not ready yet.
echelon 1y ago
XSLT just needs a different, non-XML serialization. XML (the data structure) needs a non-XML serialization. Similar to how Semantic Web's Owl has four different serializations, only one of them being the XML serialization. (eg. Owl can be represented in Functional, Turtle, Manchester, Json, and N-triples syntaxes.)
- alganet 1y ago
  > XML (the data structure) needs a non-XML serialization. That's YAML, and it is arguibly worse. Here's a sample YAML 1.2 document straight from their spec: %TAG !e! tag:example.com,2000:app/ --- - !local foo - !!str bar - !e!tag%21 baz Nightmare fuel. Just by looking at it, can you tell what it does? -- Some notes: - SemWeb also has JSON-LD serialization. It's a good compromise that fits modern tooling nicely. - XML is still a damn good compromise between human readable and machine readable. Not perfect, but what is perfect anyway? - HTML5 is now more complex than XHTML ever was (all sorts of historical caveats in this claim, I know, don't worry). - Markup beauty is relative, we should accept that.
- jimbokun 1y ago
  You're looking for S-expressions.
  - SkiFire13 1y ago
    S-expressions only represent nested lists. You need some other convention _on top of them_ to represent other kind of data, and that's generally the hard part.
- marcosdumay 1y ago
  > XML (the data structure) needs a non-XML serialization. KDL is a very interesting attempt, but my impression is that people are already trying to shove way too much unnecessary complexity into it. IMO, the KDL's document transformation is not a really good example of a better XSLT, tough. I mean, it's better, but it probably can still be improved a lot.
- bokchoi 1y ago
amy214 1y ago
Just to add to this, we know have XXSLT which solves a lot of the original problems with XSLT. Just to frame this people, imagine a JSON-based programming language for transforming JSON files into other JSON files and the program is also in JSON and turing complete. Now imagine it's not JSON but XML! Now any program can read it! Universal code, magic! The idea behind XXSLT is now, we actually have a program whose job it is to specify a program. So we have a XML file which specifies a second XML file, which is the program, whose job it is to transform XML to XML. As we all know, layers of abstraction are always good, and common formats such as XML are especially good, so what we have now is the ability to generate a whole family and diverse ontology of programs, all of them XML, all of them by and for XML. Imagine the compiling with your favourite XML-based compilation chain!

sam_lowry_ 1y ago

Keys were a thing in XSLT 1.x already. XSLT 2+ was more about side effects. I never really grokked later XSLT and XPath standards though. XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous. Newer standards lost elegance and kept the ugly syntax. No wonder they lost mindshare.

jerf 1y ago
"Newer standards lost elegance and kept the ugly syntax." My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language. When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that I really don't like. And I speak Haskell, so the critic reaching for the reply button can take a pass on the "Oh you must not like functional programming" routine... no, Haskell is included in that set of "literally any other general purpose programming language" above.
- yoz 1y ago
  Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new? There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades. [1] https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...
  - jerf 1y ago
    It would at least be an interesting project. If someone put the elbow grease into it it is distinctly possible that an XSLT stylesheet could be not just converted to JS (which is obviously true and just a matter of effort), but converted to something that is at least on the edge of human usable and editable, and some light refactoring away from being decent code.
  - bokchoi 1y ago
    I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro
    - sam_lowry_ 1y ago
      SLAX is great, unfortunately it was released a bit too late. XML world is full of ugly standards and failed contenders. None remembers RelaxNG. But had reacher expressive power than XMLSchema and a human-readable syntax.
      - bokchoi 1y ago
        Schematron!
- smrtinsert 1y ago
  Pretty true. I created a simplified XPath layer to a stax parser back in the day and it was a break through in xml usability.
bokchoi 1y ago
I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly: https://github.com/Juniper/libslax/wiki/Intro https://github.com/Juniper/libslax/wiki/Intro It looks like it was developed by Juniper and has shipped in their routers?

thechao 1y ago

Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.

badmintonbaseba 1y ago
I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.
- dolmen 1y ago
  libxslt, despites being available widely, must not be recommended. https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/ https://lwn.net/SubscriberLink/1025971/73f269ad3695186d/
jraph 1y ago
- Browsers are XSLT (1.0) processors. - Xee: https://github.com/Paligo/xee https://github.com/Paligo/xee - xrust: https://docs.rs/xrust/latest/xrust/xslt/ https://docs.rs/xrust/latest/xrust/xslt/ - XJSLT (compiles XSLT to JS): https://github.com/egh/xjslt https://github.com/egh/xjslt Xee is WIP AFAIK and I don't know the maturity of xrust and XJSLT.
- thechao 1y ago
  Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well! Also, I want a cookie & a pony.
  - jraph 1y ago
    I guess Xee is the most promising option then :-) But indeed not ready yet.

echelon 1y ago

XSLT just needs a different, non-XML serialization. XML (the data structure) needs a non-XML serialization. Similar to how Semantic Web's Owl has four different serializations, only one of them being the XML serialization. (eg. Owl can be represented in Functional, Turtle, Manchester, Json, and N-triples syntaxes.)

alganet 1y ago
> XML (the data structure) needs a non-XML serialization. That's YAML, and it is arguibly worse. Here's a sample YAML 1.2 document straight from their spec: %TAG !e! tag:example.com,2000:app/ --- - !local foo - !!str bar - !e!tag%21 baz Nightmare fuel. Just by looking at it, can you tell what it does? -- Some notes: - SemWeb also has JSON-LD serialization. It's a good compromise that fits modern tooling nicely. - XML is still a damn good compromise between human readable and machine readable. Not perfect, but what is perfect anyway? - HTML5 is now more complex than XHTML ever was (all sorts of historical caveats in this claim, I know, don't worry). - Markup beauty is relative, we should accept that.
jimbokun 1y ago
You're looking for S-expressions.
- SkiFire13 1y ago
  S-expressions only represent nested lists. You need some other convention _on top of them_ to represent other kind of data, and that's generally the hard part.
marcosdumay 1y ago
> XML (the data structure) needs a non-XML serialization. KDL is a very interesting attempt, but my impression is that people are already trying to shove way too much unnecessary complexity into it. IMO, the KDL's document transformation is not a really good example of a better XSLT, tough. I mean, it's better, but it probably can still be improved a lot.
bokchoi 1y ago

amy214 1y ago

Just to add to this, we know have XXSLT which solves a lot of the original problems with XSLT. Just to frame this people, imagine a JSON-based programming language for transforming JSON files into other JSON files and the program is also in JSON and turing complete. Now imagine it's not JSON but XML! Now any program can read it! Universal code, magic! The idea behind XXSLT is now, we actually have a program whose job it is to specify a program. So we have a XML file which specifies a second XML file, which is the program, whose job it is to transform XML to XML. As we all know, layers of abstraction are always good, and common formats such as XML are especially good, so what we have now is the ability to generate a whole family and diverse ontology of programs, all of them XML, all of them by and for XML. Imagine the compiling with your favourite XML-based compilation chain!