upvote

points

by nithril6 hours ago |
comments
upvoteby sam_lowry_5 hours ago|
next
[-]
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.

reply
upvoteby jerf4 hours ago|
parent|
[-]
"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.

reply
upvoteby yoz55 minutes ago|
parent|
[-]
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...

reply
upvoteby jerf17 minutes ago|
parent|
[-]
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.
reply
upvoteby echelon4 hours ago|
prev|
next
[-]
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.)

reply
upvoteby alganet3 hours ago|
parent|
[-]
> 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.

reply
upvoteby thechao4 hours ago|
prev|
[-]
Can you name a non-Saxon XSLT processor? I'd really like one. Preferably, open-source.
reply
upvoteby jraph2 hours ago|
parent|
next
[-]
- Browsers are XSLT (1.0) processors.

- Xee: https://github.com/Paligo/xee

- xrust: https://docs.rs/xrust/latest/xrust/xslt/

- XJSLT (compiles XSLT to JS): https://github.com/egh/xjslt

Xee is WIP AFAIK and I don't know the maturity of xrust and XJSLT.

reply
upvoteby badmintonbaseba2 hours ago|
parent|
prev|
[-]
I only know libxslt, but it's XSLT 1.0 and some of EXSLT. I don't recommend.
reply