> XPath (which is procedural)

XPath is not procedural. It is entirely composed of expressions that compose and return results. The closest common language might be SQL.

Fair ‘nuff. I consider it “more proceduralish” than XSLT. It’s really more like an FP language.

I learned XSLT twice. The first in the very early 2000s when I was creating a large and mostly static website for a magazine with a lot of content, and mostly just hacked it together. It was ok but mostly I was using it as a simple templating language. The second time was about five years ago, as a module in my MSc, by which time I was well-versed in functional programming — this time it was easy to do all sorts of weird and wonderful stuff, including a TAP-outputting assertion library for templates written in XSLT itself and a library for doing depth-first searches over graphs of nodes.

XSLT is mainly used to transform XML into XML. The resulting document doesn’t have to be XML, though. I remember being assigned a task of parsing and importing a large XML document into a MySQL database. This was supposed to be done on PHP. I kind of felt repulsed by the idea of writing the parser in PHP (it would have been horrible). So, I used XSLT to transform the document into CSV and then just imported it using LOAD DATA. Worked like a charm.

In the beginning of my career, about 15 years ago, I had a job working with a large auto parts retailer and they had all of their products in these massive XML files. We used XSLT to transform those into all kinds of things, including physical printed catalogues that would go in their stores. Obviously the XSLT didn't actually print catalogues, but we did turn them into some format that I forget now (maybe PDF!) that we could just send straight to the printers.

It was pain and suffering developing these style sheets, but once done it worked like a charm.

That must have been XSL-FO, a W3C standard. There are several implementations, like Apache FOP, that turn XSL-FO into PDF.

That's nice. I was in the same line of work. Started from building our own XML parser, when there were none available yet. Later I developed this fun XSLT that generated a fullblown Forms UI based on an XML and/or XML Schema which we used in a custom CMS. Then with XSL-FO and Quark XPress we generated user manuals and product catalogues from that. The XSLT was surprisingly fast for the time, and given the transformations it needed to do.

> Obviously the XSLT didn't actually print catalogues, but we did turn them into some format that I forget now (maybe PDF!) that we could just send straight to the printers.

Was Adobe FrameMaker involved?

Later versions of XSLT added support for more high-level output formats - JSON etc.

One of the big problems with XSLT, is that XSLT only started to become useful after Version 2.0, and wasn’t supported by languages at that level. This was the main reason I stopped using it.

2.0 was (maybe still is?) supported by Saxon, a proprietary library, needing to be licensed. Built-in support was capped at 1.5.

If I remember, in order to run XSLT 2.0, you had to license and install Saxon on your server (i believe it was a Java application, meaning the server need to have a JVM), then call it, using system calls. Awkward, at best.

But this was many moons ago. I suspect/hope that things have improved, since then.

Saxon has an open source version that supports XSLT 3.0.

XQuery 3.1 has multiple open source implementations: Saxon, BaseX, xidel, and xqerl.

If you are coming from FP, XQuery is arguably a better fit. You lose template matching, but the syntax is much more concise (although still verbose by PL standards).