7 ms·

XSLT: A Precision Tool for the Future of Structured Transformation

58 points by protomolecool 1y ago

russellbeattie 1y ago
It's amusing - I still have a visceral negative reaction to XSLT. I can't help it. I spent a couple years down that rabbit hole before realizing what a dead end it all was. I wrote and used my own publishing system using a custom pipeline of transforms, and started down the path of making a UI using XML and dynamic XSLT templates and more. All with a backend of Java and Enterprise Java Beans. The regret I feel about all this is palpable. I desperately want those hours and hours of coding back.
egberts1 1y ago
Virtual Machine Management tookit/library (libvirt, libvirtd daemon) makes intensive use of XML in its configuration files. Virtual Machine Management CLI insulated the end-user of any XML. Virtual Machine Manager GUI (virt-manager) too but also allows end-user to tweak XML directly as well as its GUI ease of use. Only time that I direct-edit libvirt XML configuration file is to do a DMA passthru setting for NVIDIA CUDA for direct access by VMs. https://wiki.gentoo.org/wiki/Libvirt https://wiki.gentoo.org/wiki/Libvirt https://wiki.gentoo.org/wiki/Virsh https://wiki.gentoo.org/wiki/Virsh https://wiki.gentoo.org/wiki/Virt-manager https://wiki.gentoo.org/wiki/Virt-manager
jest3r1337 1y ago
I have prepared my popcorn. Now go, YAML vs. XML vs. JASON vs. TOML vs. ??ML
- cmrdporcupine 1y ago
  EDN format is best format: https://github.com/edn-format/edn https://github.com/edn-format/edn
  - kstrauser 1y ago
    That’s close enough to sexprs, the One True Format, that I’ll allow it.
    - drob518 1y ago
      IMO, it’s sexprs on steroids. All the goodness of Lisp sexprs with terse (!) support of useful concepts like vectors, maps, and sets.
    - cmrdporcupine 1y ago
      yeah just some explicit allowance for associative data (maps)
      - kstrauser 1y ago
        That's a worthy addition that covers pretty much any use case I'd have.
    - sunshine-o 1y ago
      In a parallel universe the web was built on sexprs and Lisp instead of HTML/XML and JavaScript. That civilization ascended but we did not.
      - em-bee 1y ago
        in the early 90s i was interested in a better webserver than the ones from ncsa or cern. i read something about a webserver written in common lisp and acquired a common lisp implementation for linux from franz inc. then i started this server and discovered that it could not serve files out of the box like ncsa and cern did. it expected me to write code to serve (dynamically generated) pages. i kept looking and then discovered spinner/roxen, which did serve static files and had a different approach to dynamic pages which was more similar to server side includes and thus easier to approach than the common lisp server. if that common lisp server would have been able to serve the static files that i already had out of the box, allowing a slow transition to more dynamic pages, i might have stuck with it...
- lorenzohess 1y ago
  Akchually YAML is a superset of JASON
  - milliams 1y ago
    Akchually only the YAML JSON (and therefore also the Core) Schema (https://yaml.org/spec/1.2.2/#102-json-schema https://yaml.org/spec/1.2.2/#102-json-schema) is a superset of JSON. The Failsafe Schema is not.
- tonyedgecombe 1y ago
  I'm willing to forgive all these format's sins simply because I spent so much time in the eighties and early nineties dealing with all the retched and poorly documented bespoke formats people came up with before these existed. It was a breath of fresh air to be able to tell customers their XML file doesn't validate hence it is their problem not mine.
diulin 1y ago
XML/XSLT/XPath are great, but XSLT ecosystem has been effectively "frozen" for over a decade in terms of innovation and tooling. The last major step was XSLT 3.0 (2017), which introduced streaming and function integration. However, in practice, no new engines or radically different approaches have emerged since then. And there is only one free XSLT 3.0 processor available, SAXON-HE (it lacks schema-aware & streaming though)
- sbennettmcleish 1y ago
  I'd say damn near 20yrs. I used it quite extensively about 10yrs ago and it was an odd one then, but was very useful for the purpose we had (semantic validation of XML payloads).
- jerf 1y ago
  XSLT is a bad programming language wrapped around XPath. I'd rather take any existing general purpose programming language, add an XPath library to it, and write anything I'd do in XSLT in a programming language where I don't have to wait until version 3.0 for, well, all this stuff: https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3 https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3 And a lot of that "badness" is precisely that XSLT is a very closed, scarcity-minded language where basic library and language features have to be routed through a standards committee (you think it's hard to get a new function into Python's or Go's standard library?), when all you really need is an XPath library and any abundance-mindset language you can pick up, where if you need something like "regular expression" support you can just go get a library. Or literally anything else you may need to process an XML document, which is possibly anything. Which is why a general-purpose language is a good fit. That "What's New In XSLT 3.0" is lunatic nonsense if you view it through the lens of being a programming language. What programming language gets associative arrays after 18 years? And another 8 years after that you still can't really count on that being available? Programming languages tend to have either success feed success, or failure feed failure. Once one of those cascades start it's very difficult to escape from them. XSLT is pretty firmly in the latter camp, probably kept alive only by the fact it's a standard and that still matters to some people. It's frozen because effectively nobody cares, because it's frozen, because nobody cares. I definitely recommend putting XPath in your toolbelt if you have to deal with XML at all though.
johannes1234321 1y ago
Oh what filun it was when Internet Explorer supported XSLT natively ... have your webpage content in an RSS file or similar, add XSLT Stylesheet reference and the browser would render it as nice web page. Nice way to have a single page blog without server side code, no generator step or anything. But well, Firefox didn't do it that way, thus no proper use.
- palsecam 1y ago
  Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml https://paul.fragara.com/feed.xml as an example (the Atom feed of my website, styled with XSLT). FTR, there’s also XSLTProcessor (https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...) available from Javascript in the browser. I use that on my homepage, to fetch and transform-to-HTML said Atom feed, then embed it: const atom = new XMLHttpRequest, xslt = new XMLHttpRequest; atom.open("GET", "feed.xml"); xslt.open("GET", "atom2html.xsl"); atom.onload = xslt.onload = function() { if (atom.readyState !== 4 || xslt.readyState !== 4) return; const proc = new XSLTProcessor; proc.importStylesheet(xslt.responseXML); const frag = proc.transformToFragment(atom.responseXML, document); document.getElementById("feed").appendChild(frag.querySelector("[role='feed']")); }; atom.send(); xslt.send(); Server-side, I’ve leveraged XSLT (2.0) in the build process of another website, to slightly transform (X)HTML pages before publishing (canonicalize URLs, embed JS & CSS directly in the page, etc.): https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.xsl https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.x...
  - johannes1234321 1y ago
    Interesting, it's more than 20 years since I tried anything in that space. Thanks for the correction.
- naniwaduni 1y ago
  To this day, XSLT is one of basically two ways to deliver "content" and "layout" almost fully separately and have a browser combine that in a presentable way, entirely on the client—the other, of course, being to make a mess in JS.
jbeard4 1y ago
I love XSLT. I wrote a SCXML-to-JavaScript compiler in it back in 2010: https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/ https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/s... Written as a pipeline of XSLT transformations. Ran natively in the browser to execute SCXML documents to control UI logic. Good times.
sachahjkl 1y ago
>Its predictable, rule-based execution model reduces maintenance effort and makes it easier to onboard new developers into a project > — when written well LMAO
ChrisMarshallNY 1y ago
When they support XSLT 2.0/3.0 in libxml/libxsl, then it will be interesting. Until then, no dice.
- sam_lowry_ 1y ago
  XSLT up to 1.1 is a totally different language, actually.
  - ChrisMarshallNY 1y ago
    Yup. It's also almost worthless. The fun starts at 2.0.
    - sam_lowry_ 1y ago
      I admire 1.1. It is elegant as poetry is compared to prose. You really had to bend your mind to do things with it. Like... grouping had to be invented by Steve(?) Muench before anyone could do it. This is why it was called Muenchian grouping. OTOH, later XSLT versions are just badly designed programming languages with a weird syntax. No wonder none wants to use them. Funnily only one guy kind of succeeded to implement them, the editor of the spec and the author of Saxon himself )) I am sure he earned many millions since then on obscure contracts with the likes of SAP and Oracle.
      - ChrisMarshallNY 1y ago
        I appreciate that, but my experience was that (like poetry), I could not actually make it do anything practical. It was quite difficult to learn, and when I did, I found that I could write stuff that almost worked, but not quite…
      - masklinn 1y ago
        > It is elegant as poetry is compared to prose. Not poetry that's any good though. > OTOH, later XSLT versions are just badly designed programming languages with a weird syntax. Not that XSLT 1.x was anything other than that, later version were just piling garbage on a foundation which would have been better not existing in the first place.
zabil 1y ago
One thing I really appreciated during the peak years of working with XSLT was how much I learned about XPath. Once it clicks, it’s surprisingly intuitive and powerful. I don’t use XSLT much these days, but I still find myself using XPath occasionally. It’s one of those tools—once you understand it, it sticks with you.
Devasta 1y ago
Abandoning XML is and continues to be the webs biggest mistake. Client side templating, custom elements, validation against schemas, native databinding for forms, we could have had it all and threw it away; instead preferring to rebuild it over and over again in React until the end of time.
- kelseyfrog 1y ago
  It was actually a hypertext format as opposed to JSON. So HATEOS actually made sense. The fact that we went backwards in terms of no longer using a hyptertext format for almost all web requests is one of the dumbest moves in web development. I get the incentives that influenced it, but yuck.
  - Devasta 1y ago
    If the web was being built today it would be nothing but Javascript and Canvas, the idea of something like HTML would have you laughed out of the room. Documents? You have PDF for that.
DonHopkins 1y ago
My impression of XSLT is that there were representatives from every different programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough of what was special about their own paradigm into the standard to showcase it while sabotaging the others and making them all look foolish, but not enough to actually get any work done or lord forbid synergistically dovetail together into a unified whole. The only way I was ever able to get anything done with XLST was to use Microsoft's script extensions to drop down into JavaScript and just solve the problem with a few lines of code. And that begs the question of why am I not just solving this problem with a few lines of JavaScript code instead of inviting XSLT to the party? More on XML, XSLT, SGML, DSSSL, and the DDJ interview "A Triumph of Simplicity: James Clark on Markup Languages and XML": https://news.ycombinator.com/item?id=33728303 https://news.ycombinator.com/item?id=33728303
ryoshu 1y ago
Timely. Have an ask from a client and the best solution seems to be XSLT.
blixt 1y ago
I haven't used XSLT since 2007 but I used it as an alternative to ASP.NET for building some dynamic but not too advanced websites and it had a very impressive performance when cached properly (I believe it was over an order of magnitude faster than just default ASP.NET). I went sleuthing for the framework but I think it's lost. Also the Google Code archive is barely functional anymore, but I did find the XSLT cache function I built for it: https://github.com/blixt/old-google-code-svn/blob/main/trunk/cs/XsltCache/XsltCache.cs https://github.com/blixt/old-google-code-svn/blob/main/trunk... Pretty cool to see XSLT mentioned in 2025!
hungryhobbit 1y ago
XSLT is basically regular expressions on steroids: you can do incredibly powerful things with it, fairly quickly ... but good luck understanding the code you wrote when you read it the next day.
PaulHoule 1y ago
XSLT is part of the strange story of why production rules, the basis of many "expert systems" and once thought to have a bright future, never became a mainstream technique in computing. If somebody were really interested in bring XSLT into the 2020 the best bet may be to drop the XML bit and ask questions like: how do I use production rules to transform a POJO (plain ordinary Java object) into another object, how do I use production rules to transform JSON documents, transform XML/JSON/HTML bidirectionally to and from platform objects, etc. Based on XML it is just too easy to get into the weeds like "should this be represented as an attribute or an child element", namespaces, entities and so many details that get in the way of seeing XSLT for what it is.
mcv 1y ago
I did a lot of XSLT 20 years ago. I worked for a company making an open source CMS that did everything in XML. Content was XML, obviously, pipelines (using Apache Cocoon) were defined in XML, and used XSLT to transform XML into different XML. We got quite proficient in it. We even used XSLT to generate XSLT. A Coworker figured out how to calculate a square root in XSLT (not for production obviously). It's fun to work in such a declarative way, although all the XML gets tiring. I learned a ton there, though. XSLT is great for its intended purpose, but maybe the fact that you can also use it for other things is a risk. XPath is probably the most useful part of it.
- PaulHoule 1y ago
  It's a problem in both the XML and RDF [1] worlds that the same representation gets used for everything. Part of the success of CSS is that it looks different from HTML, it could have been expressed with angle brackets and I think people would have had terrible trouble understanding where the HTML ends and the CSS begins. [1] Oddly, SPARQL-in-Turtle isn't half bad to my eye, see https://spinrdf.org/sp.html https://spinrdf.org/sp.html
- sunshine-o 1y ago
  Cocoon was cool but damn that thing was slow. At the end you had to do a lot of caching to end up with something usable.
  - mcv 1y ago
    Cocoon was indeed my first exposure to the wonderful world of caching. I used Cocoon's event caching to create a preemptive caching for a particularly complicated situation.
starkparker 1y ago
> It excels in: Modular publishing workflows (DITA Stopped reading here because the XSLT story with DITA-OT is so godawful that it's been the primary driver to move off DITA altogether at nearly every place I've worked at or with that used it. The one exception spent nearly $1M/year on third-party tooling to get away from having to deal with it, and that tooling under the hood was a Mechanical Turk support engineer writing the XSLTs for their weird-ass custom req.
password4321 1y ago
XSLT trending back up? -- XMLUI https://news.ycombinator.com/item?id=44625292#44625559 https://news.ycombinator.com/item?id=44625292#44625559 (~30/317 comments; yesterday) > No mention of XSLT? (interesting mention of a better way, vintage "kiselyov's SXML/SSAX" for scheme - https://ssax.sourceforge.net/ https://ssax.sourceforge.net/ ?) -- XSLT – Native, zero-config build system for the Web https://news.ycombinator.com/item?id=44393817 https://news.ycombinator.com/item?id=44393817 (328 comments; ~month ago)

58 points by protomolecool 1y ago

It's amusing - I still have a visceral negative reaction to XSLT. I can't help it. I spent a couple years down that rabbit hole before realizing what a dead end it all was. I wrote and used my own publishing system using a custom pipeline of transforms, and started down the path of making a UI using XML and dynamic XSLT templates and more. All with a backend of Java and Enterprise Java Beans. The regret I feel about all this is palpable. I desperately want those hours and hours of coding back.

egberts1 1y ago

Virtual Machine Management tookit/library (libvirt, libvirtd daemon) makes intensive use of XML in its configuration files. Virtual Machine Management CLI insulated the end-user of any XML. Virtual Machine Manager GUI (virt-manager) too but also allows end-user to tweak XML directly as well as its GUI ease of use. Only time that I direct-edit libvirt XML configuration file is to do a DMA passthru setting for NVIDIA CUDA for direct access by VMs. https://wiki.gentoo.org/wiki/Libvirt https://wiki.gentoo.org/wiki/Libvirt https://wiki.gentoo.org/wiki/Virsh https://wiki.gentoo.org/wiki/Virsh https://wiki.gentoo.org/wiki/Virt-manager https://wiki.gentoo.org/wiki/Virt-manager

jest3r1337 1y ago

I have prepared my popcorn. Now go, YAML vs. XML vs. JASON vs. TOML vs. ??ML

cmrdporcupine 1y ago
EDN format is best format: https://github.com/edn-format/edn https://github.com/edn-format/edn
- kstrauser 1y ago
  That’s close enough to sexprs, the One True Format, that I’ll allow it.
  - drob518 1y ago
    IMO, it’s sexprs on steroids. All the goodness of Lisp sexprs with terse (!) support of useful concepts like vectors, maps, and sets.
  - cmrdporcupine 1y ago
    yeah just some explicit allowance for associative data (maps)
    - kstrauser 1y ago
      That's a worthy addition that covers pretty much any use case I'd have.
  - sunshine-o 1y ago
    In a parallel universe the web was built on sexprs and Lisp instead of HTML/XML and JavaScript. That civilization ascended but we did not.
    - em-bee 1y ago
      in the early 90s i was interested in a better webserver than the ones from ncsa or cern. i read something about a webserver written in common lisp and acquired a common lisp implementation for linux from franz inc. then i started this server and discovered that it could not serve files out of the box like ncsa and cern did. it expected me to write code to serve (dynamically generated) pages. i kept looking and then discovered spinner/roxen, which did serve static files and had a different approach to dynamic pages which was more similar to server side includes and thus easier to approach than the common lisp server. if that common lisp server would have been able to serve the static files that i already had out of the box, allowing a slow transition to more dynamic pages, i might have stuck with it...
lorenzohess 1y ago
Akchually YAML is a superset of JASON
- milliams 1y ago
  Akchually only the YAML JSON (and therefore also the Core) Schema (https://yaml.org/spec/1.2.2/#102-json-schema https://yaml.org/spec/1.2.2/#102-json-schema) is a superset of JSON. The Failsafe Schema is not.
tonyedgecombe 1y ago
I'm willing to forgive all these format's sins simply because I spent so much time in the eighties and early nineties dealing with all the retched and poorly documented bespoke formats people came up with before these existed. It was a breath of fresh air to be able to tell customers their XML file doesn't validate hence it is their problem not mine.

diulin 1y ago

XML/XSLT/XPath are great, but XSLT ecosystem has been effectively "frozen" for over a decade in terms of innovation and tooling. The last major step was XSLT 3.0 (2017), which introduced streaming and function integration. However, in practice, no new engines or radically different approaches have emerged since then. And there is only one free XSLT 3.0 processor available, SAXON-HE (it lacks schema-aware & streaming though)

sbennettmcleish 1y ago
I'd say damn near 20yrs. I used it quite extensively about 10yrs ago and it was an odd one then, but was very useful for the purpose we had (semantic validation of XML payloads).
jerf 1y ago
XSLT is a bad programming language wrapped around XPath. I'd rather take any existing general purpose programming language, add an XPath library to it, and write anything I'd do in XSLT in a programming language where I don't have to wait until version 3.0 for, well, all this stuff: https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3 https://www.w3.org/TR/xslt-30/#whats-new-in-xslt3 And a lot of that "badness" is precisely that XSLT is a very closed, scarcity-minded language where basic library and language features have to be routed through a standards committee (you think it's hard to get a new function into Python's or Go's standard library?), when all you really need is an XPath library and any abundance-mindset language you can pick up, where if you need something like "regular expression" support you can just go get a library. Or literally anything else you may need to process an XML document, which is possibly anything. Which is why a general-purpose language is a good fit. That "What's New In XSLT 3.0" is lunatic nonsense if you view it through the lens of being a programming language. What programming language gets associative arrays after 18 years? And another 8 years after that you still can't really count on that being available? Programming languages tend to have either success feed success, or failure feed failure. Once one of those cascades start it's very difficult to escape from them. XSLT is pretty firmly in the latter camp, probably kept alive only by the fact it's a standard and that still matters to some people. It's frozen because effectively nobody cares, because it's frozen, because nobody cares. I definitely recommend putting XPath in your toolbelt if you have to deal with XML at all though.

johannes1234321 1y ago

Oh what filun it was when Internet Explorer supported XSLT natively ... have your webpage content in an RSS file or similar, add XSLT Stylesheet reference and the browser would render it as nice web page. Nice way to have a single page blog without server side code, no generator step or anything. But well, Firefox didn't do it that way, thus no proper use.

palsecam 1y ago
Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml https://paul.fragara.com/feed.xml as an example (the Atom feed of my website, styled with XSLT). FTR, there’s also XSLTProcessor (https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcess...) available from Javascript in the browser. I use that on my homepage, to fetch and transform-to-HTML said Atom feed, then embed it: const atom = new XMLHttpRequest, xslt = new XMLHttpRequest; atom.open("GET", "feed.xml"); xslt.open("GET", "atom2html.xsl"); atom.onload = xslt.onload = function() { if (atom.readyState !== 4 || xslt.readyState !== 4) return; const proc = new XSLTProcessor; proc.importStylesheet(xslt.responseXML); const frag = proc.transformToFragment(atom.responseXML, document); document.getElementById("feed").appendChild(frag.querySelector("[role='feed']")); }; atom.send(); xslt.send(); Server-side, I’ve leveraged XSLT (2.0) in the build process of another website, to slightly transform (X)HTML pages before publishing (canonicalize URLs, embed JS & CSS directly in the page, etc.): https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.xsl https://github.com/PaulCapron/pwa2uwp/blob/master/postprod.x...
- johannes1234321 1y ago
  Interesting, it's more than 20 years since I tried anything in that space. Thanks for the correction.
naniwaduni 1y ago
To this day, XSLT is one of basically two ways to deliver "content" and "layout" almost fully separately and have a browser combine that in a presentable way, entirely on the client—the other, of course, being to make a mess in JS.

jbeard4 1y ago

I love XSLT. I wrote a SCXML-to-JavaScript compiler in it back in 2010: https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/scxml-js/trunk/ https://svn.apache.org/repos/asf/commons/sandbox/gsoc/2010/s... Written as a pipeline of XSLT transformations. Ran natively in the browser to execute SCXML documents to control UI logic. Good times.

sachahjkl 1y ago

>Its predictable, rule-based execution model reduces maintenance effort and makes it easier to onboard new developers into a project > — when written well LMAO

ChrisMarshallNY 1y ago

When they support XSLT 2.0/3.0 in libxml/libxsl, then it will be interesting. Until then, no dice.

sam_lowry_ 1y ago
XSLT up to 1.1 is a totally different language, actually.
- ChrisMarshallNY 1y ago
  Yup. It's also almost worthless. The fun starts at 2.0.
  - sam_lowry_ 1y ago
    I admire 1.1. It is elegant as poetry is compared to prose. You really had to bend your mind to do things with it. Like... grouping had to be invented by Steve(?) Muench before anyone could do it. This is why it was called Muenchian grouping. OTOH, later XSLT versions are just badly designed programming languages with a weird syntax. No wonder none wants to use them. Funnily only one guy kind of succeeded to implement them, the editor of the spec and the author of Saxon himself )) I am sure he earned many millions since then on obscure contracts with the likes of SAP and Oracle.
    - ChrisMarshallNY 1y ago
      I appreciate that, but my experience was that (like poetry), I could not actually make it do anything practical. It was quite difficult to learn, and when I did, I found that I could write stuff that almost worked, but not quite…
    - masklinn 1y ago
      > It is elegant as poetry is compared to prose. Not poetry that's any good though. > OTOH, later XSLT versions are just badly designed programming languages with a weird syntax. Not that XSLT 1.x was anything other than that, later version were just piling garbage on a foundation which would have been better not existing in the first place.

zabil 1y ago

One thing I really appreciated during the peak years of working with XSLT was how much I learned about XPath. Once it clicks, it’s surprisingly intuitive and powerful. I don’t use XSLT much these days, but I still find myself using XPath occasionally. It’s one of those tools—once you understand it, it sticks with you.

Devasta 1y ago

Abandoning XML is and continues to be the webs biggest mistake. Client side templating, custom elements, validation against schemas, native databinding for forms, we could have had it all and threw it away; instead preferring to rebuild it over and over again in React until the end of time.

kelseyfrog 1y ago
It was actually a hypertext format as opposed to JSON. So HATEOS actually made sense. The fact that we went backwards in terms of no longer using a hyptertext format for almost all web requests is one of the dumbest moves in web development. I get the incentives that influenced it, but yuck.
- Devasta 1y ago
  If the web was being built today it would be nothing but Javascript and Canvas, the idea of something like HTML would have you laughed out of the room. Documents? You have PDF for that.

DonHopkins 1y ago

My impression of XSLT is that there were representatives from every different programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough of what was special about their own paradigm into the standard to showcase it while sabotaging the others and making them all look foolish, but not enough to actually get any work done or lord forbid synergistically dovetail together into a unified whole. The only way I was ever able to get anything done with XLST was to use Microsoft's script extensions to drop down into JavaScript and just solve the problem with a few lines of code. And that begs the question of why am I not just solving this problem with a few lines of JavaScript code instead of inviting XSLT to the party? More on XML, XSLT, SGML, DSSSL, and the DDJ interview "A Triumph of Simplicity: James Clark on Markup Languages and XML": https://news.ycombinator.com/item?id=33728303 https://news.ycombinator.com/item?id=33728303

ryoshu 1y ago

Timely. Have an ask from a client and the best solution seems to be XSLT.

blixt 1y ago

I haven't used XSLT since 2007 but I used it as an alternative to ASP.NET for building some dynamic but not too advanced websites and it had a very impressive performance when cached properly (I believe it was over an order of magnitude faster than just default ASP.NET). I went sleuthing for the framework but I think it's lost. Also the Google Code archive is barely functional anymore, but I did find the XSLT cache function I built for it: https://github.com/blixt/old-google-code-svn/blob/main/trunk/cs/XsltCache/XsltCache.cs https://github.com/blixt/old-google-code-svn/blob/main/trunk... Pretty cool to see XSLT mentioned in 2025!

hungryhobbit 1y ago

XSLT is basically regular expressions on steroids: you can do incredibly powerful things with it, fairly quickly ... but good luck understanding the code you wrote when you read it the next day.

PaulHoule 1y ago

XSLT is part of the strange story of why production rules, the basis of many "expert systems" and once thought to have a bright future, never became a mainstream technique in computing. If somebody were really interested in bring XSLT into the 2020 the best bet may be to drop the XML bit and ask questions like: how do I use production rules to transform a POJO (plain ordinary Java object) into another object, how do I use production rules to transform JSON documents, transform XML/JSON/HTML bidirectionally to and from platform objects, etc. Based on XML it is just too easy to get into the weeds like "should this be represented as an attribute or an child element", namespaces, entities and so many details that get in the way of seeing XSLT for what it is.

mcv 1y ago

I did a lot of XSLT 20 years ago. I worked for a company making an open source CMS that did everything in XML. Content was XML, obviously, pipelines (using Apache Cocoon) were defined in XML, and used XSLT to transform XML into different XML. We got quite proficient in it. We even used XSLT to generate XSLT. A Coworker figured out how to calculate a square root in XSLT (not for production obviously). It's fun to work in such a declarative way, although all the XML gets tiring. I learned a ton there, though. XSLT is great for its intended purpose, but maybe the fact that you can also use it for other things is a risk. XPath is probably the most useful part of it.

PaulHoule 1y ago
It's a problem in both the XML and RDF [1] worlds that the same representation gets used for everything. Part of the success of CSS is that it looks different from HTML, it could have been expressed with angle brackets and I think people would have had terrible trouble understanding where the HTML ends and the CSS begins. [1] Oddly, SPARQL-in-Turtle isn't half bad to my eye, see https://spinrdf.org/sp.html https://spinrdf.org/sp.html
sunshine-o 1y ago
Cocoon was cool but damn that thing was slow. At the end you had to do a lot of caching to end up with something usable.
- mcv 1y ago
  Cocoon was indeed my first exposure to the wonderful world of caching. I used Cocoon's event caching to create a preemptive caching for a particularly complicated situation.

starkparker 1y ago

> It excels in: Modular publishing workflows (DITA Stopped reading here because the XSLT story with DITA-OT is so godawful that it's been the primary driver to move off DITA altogether at nearly every place I've worked at or with that used it. The one exception spent nearly $1M/year on third-party tooling to get away from having to deal with it, and that tooling under the hood was a Mechanical Turk support engineer writing the XSLTs for their weird-ass custom req.

password4321 1y ago

XSLT trending back up? -- XMLUI https://news.ycombinator.com/item?id=44625292#44625559 https://news.ycombinator.com/item?id=44625292#44625559 (~30/317 comments; yesterday) > No mention of XSLT? (interesting mention of a better way, vintage "kiselyov's SXML/SSAX" for scheme - https://ssax.sourceforge.net/ https://ssax.sourceforge.net/ ?) -- XSLT – Native, zero-config build system for the Web https://news.ycombinator.com/item?id=44393817 https://news.ycombinator.com/item?id=44393817 (328 comments; ~month ago)