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.
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.
Oh but yes, Firefox (and Chrome) do support XSLT natively! See https://paul.fragara.com/feed.xml as an example (the Atom feed of my website, styled with XSLT).
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.x...
Firefox does support XSLT. At Standard Ebooks, our ebook OPDS/RSS feeds are styled with XSLT when viewed with a browser. See for example https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).
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.
I used XSLT and Active Server Pages to build my school district's website back around 2000 - each school had their own page and each teacher had their own, too - teachers could modify their pages directly in the browser.
I forget the _exact_ mechanics but it was definitely all done in Internet Explorer with XML as the actual content per-page and transformation was done using XSLT.
Interesting but I definitely hate XSLT as a result. Considering this was my first real programming job, it's surprising I continued.
The bigger problem was the poor experience when anything failed and your users got an inscrutable error page or, if it was a gap in functionality rather than a hard compatibility error, parts of the page didn’t work as expected and you might not even notice if depended on a browser / MS shared library version you didn’t use.
Philosophically I like the idea but that era needed a lot more attention to tool quality and interoperability. I’m not sure anything anyone on an XML-based standards committee did after the turn of the century mattered as much as it would have if the money had been spent improving tools and avoiding things like so many tools relying on libxml2 / libxslt and thus never getting support for newer versions of XPath, XSLT, etc.
Every alternative was massively better for two key reasons: the first is that it happened on the server where you knew about it and could control what happened[1], and because you only had one kind of server to monitor whereas client side errors had to be tested in a wide range of client OS and browser combinations, much larger than today where automatic updates are just taken for granted.
There was a third way in which PHP was often better: continuing after errors has drawbacks from a security and correctness perspective but as a user it was often the case that you could read what you wanted on a partially functioning page. I think we’ve largely matured out of the point where that’s good, but people often did benefit at the time.
1. remember, this was before things like Sentry happened for front end error collection, and XML-related issues still can’t be handled by JavaScript even now.
I did this in embedded some 20+ years ago, I was working on a project where the microcontroller didn't have enough resources to do much CGI and store much more than a few kilobytes, so a big dashboard with tens of temperature gauges and other things was all done as a combination of serving XML data and a single, small XSLT file and the rest was all in the browser. Fun times indeed.
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)
Even worse, in practice you still often only get to use XSLT 1 and XPath 1, because that's what the common Open Source libraries (i.e. libxml/libxslt and Xalan) typically used to embed XSLT into Software support. (The existence of EXSLT should better be forgotten). For anything else, esp. dedicated standalone XSLT development, there is basically only saxon. I wish, there was better Open Source support for XSLT/XPath 2+ but i don't think it's likely to happen.
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).
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
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.
Years ago, I was maintaining a huge XML->XML transformation in XSLT. The input format was the XML based config file of the system, that was created by the configuration tool. Output was a XML that has the same information in a way that is optimized for the system to read in efficiently. (Changing order of things, introducting redundancy by replicating similar information for different parts of the system, etc.)
(It was a Building Information System, Fire Alarms, Access, Lots of business rules stored in XML)
While the XML was easier to transform in XSLT than in the native C++, and yes, XSLT was probably the right tool at that time I developed a deep hatred for XSLT at that time. It felt like a functional language that had just all the important parts removed.
Yes, pattern matching is a good thing, but hey - I can do pattern matching for rules in any decent language. It was just the amount of existing code that prevented me from porting it to another language.
(And I remember a few ugly hacks, where I exposed "programming language" stuff from C# - which we also used - to the XSLT processor)
However, with all the XSLT ugliness: XPath is amazing! I love that.
I was wondering whether I was the only person to think XSLT was a poor tool, although for different reasons. I had to work with XSLT for several years, and it felt like the worst programming language I had ever seen. For me, the use of code written in XML to process XML felt absurd, and debugging felt next to impossible. I thought it would be nice if someone would create a library in some other programming language (maybe Prolog) that would do the same thing. If it had to first had to "compile" stuff into XSLT, so be it, but programming in XML was so verbose that I had trouble keeping track of my program's structure.
"I thought it would be nice if someone would create a library in some other programming language"
It's just XPath. Grab your favorite programming language, grab XPath, start transforming and outputting. You still probably ought to learn XPath, but unlike XSLT as a whole, learning XPath rather quickly starts paying off.
BTW, I decided I'd see if there was an XPath library for Prolog (once my favorite programming language, and with some conceptual/ algorithmic similarity to XSLT, I think, although XSLT has nothing like Prolog's backtracking). Turns out there is (at least) one: https://www.swi-prolog.org/pldoc/man?predicate=xpath%2f3.
There's a comparison of Prolog and XSLT v1 here: https://arxiv.org/pdf/1912.10817v1 (warning: poorly translated from the Russian original, and dated).
I did know XPath, although I found out the other day that I'd forgotten a lot about it. I was programming in Python using the xml.dom library, which afaict doesn't use XPath at all--I wish it did, I had a very deeply nested set of if-else and for statements to get to something that would have been a single XPath. There's another Python XML library, xml.etree, which provides some ("limited") XPath support, but I had already written most of the code I needed using the dom library when I ran into this.
I will say that for all I'm singing the praises of XPath, the online tutorials and documentation are atrocious. Possibly the worst ratio of quality to library power I've seen. I recently came back to it after a couple of years and couldn't hardly do anything either because I couldn't even reconstruct my previous understanding off of the documentation, but then I consulted my own notes and docs about it and it all came back quickly.
There are two problems. First, everyone is obsessed with trying to label it "declarative" when it is waaaaay better understood as a library for driving around a multicursor imperatively. Call it declarative if you like but I've had way more success driving it effectively imperatively.
Second, each XPath clause has three parts: The "axes", which is the "direction" you want to drive the cursor, the "node selection" which selects which nodes you are talking about (usually the tag name), and then optional filters in [], which can then itself recurse in some ways into further XPath specifications, as well as using some functions and predicates to filter. Fortunately for your convenience, there's a default axis, selecting nodes by tag name is easy, and the filters are indeed optional. Unfortunately for your understanding, there's other defaults and shortcuts and all the "tutorials" and "cheat sheets" and all that jazz teach only the shortcuts, but if you learn only the shortcuts the whole language feels random and very difficult to understand. You really need to learn the full version of the selector clause first, practice by writing it out fully a few times, and then starting to use the shortcuts.
(You can even see the "node selection" as just a type of filter that looks at the tag name most of the time, in which case there are two parts. But it's really confusing when tutorials don't distinguish very well between those two things and mangle it all up into one undifferentiated ball.)
It's not that hard if you are taught it correctly, but I have yet to find something that teaches it correctly online.
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.
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.
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.
> 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.
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...
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.
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.
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.
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.
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.
> 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.
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":
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.
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...
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.
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.
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.
Oh but yes, Firefox (and Chrome) do support XSLT natively! See 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/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:
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.x...Interesting, it's more than 20 years since I tried anything in that space. Thanks for the correction.
Firefox does support XSLT. At Standard Ebooks, our ebook OPDS/RSS feeds are styled with XSLT when viewed with a browser. See for example https://standardebooks.org/feeds/opds/new-releases (use view source to see that it's an XML document).
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.
I used XSLT and Active Server Pages to build my school district's website back around 2000 - each school had their own page and each teacher had their own, too - teachers could modify their pages directly in the browser.
I forget the _exact_ mechanics but it was definitely all done in Internet Explorer with XML as the actual content per-page and transformation was done using XSLT.
Interesting but I definitely hate XSLT as a result. Considering this was my first real programming job, it's surprising I continued.
The bigger problem was the poor experience when anything failed and your users got an inscrutable error page or, if it was a gap in functionality rather than a hard compatibility error, parts of the page didn’t work as expected and you might not even notice if depended on a browser / MS shared library version you didn’t use.
Philosophically I like the idea but that era needed a lot more attention to tool quality and interoperability. I’m not sure anything anyone on an XML-based standards committee did after the turn of the century mattered as much as it would have if the money had been spent improving tools and avoiding things like so many tools relying on libxml2 / libxslt and thus never getting support for newer versions of XPath, XSLT, etc.
Not sure the experience on failures of PHP scripts of that time was any better :)
Every alternative was massively better for two key reasons: the first is that it happened on the server where you knew about it and could control what happened[1], and because you only had one kind of server to monitor whereas client side errors had to be tested in a wide range of client OS and browser combinations, much larger than today where automatic updates are just taken for granted.
There was a third way in which PHP was often better: continuing after errors has drawbacks from a security and correctness perspective but as a user it was often the case that you could read what you wanted on a partially functioning page. I think we’ve largely matured out of the point where that’s good, but people often did benefit at the time.
1. remember, this was before things like Sentry happened for front end error collection, and XML-related issues still can’t be handled by JavaScript even now.
I did this in embedded some 20+ years ago, I was working on a project where the microcontroller didn't have enough resources to do much CGI and store much more than a few kilobytes, so a big dashboard with tens of temperature gauges and other things was all done as a combination of serving XML data and a single, small XSLT file and the rest was all in the browser. Fun times indeed.
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)
Even worse, in practice you still often only get to use XSLT 1 and XPath 1, because that's what the common Open Source libraries (i.e. libxml/libxslt and Xalan) typically used to embed XSLT into Software support. (The existence of EXSLT should better be forgotten). For anything else, esp. dedicated standalone XSLT development, there is basically only saxon. I wish, there was better Open Source support for XSLT/XPath 2+ but i don't think it's likely to happen.
There's a working group dedicated to breathing new life into the standard:
https://qt4cg.org/specifications/xslt-40/Overview.html
Last updated just under a week 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).
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
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.
Years ago, I was maintaining a huge XML->XML transformation in XSLT. The input format was the XML based config file of the system, that was created by the configuration tool. Output was a XML that has the same information in a way that is optimized for the system to read in efficiently. (Changing order of things, introducting redundancy by replicating similar information for different parts of the system, etc.)
(It was a Building Information System, Fire Alarms, Access, Lots of business rules stored in XML)
While the XML was easier to transform in XSLT than in the native C++, and yes, XSLT was probably the right tool at that time I developed a deep hatred for XSLT at that time. It felt like a functional language that had just all the important parts removed.
Yes, pattern matching is a good thing, but hey - I can do pattern matching for rules in any decent language. It was just the amount of existing code that prevented me from porting it to another language.
(And I remember a few ugly hacks, where I exposed "programming language" stuff from C# - which we also used - to the XSLT processor)
However, with all the XSLT ugliness: XPath is amazing! I love that.
I was wondering whether I was the only person to think XSLT was a poor tool, although for different reasons. I had to work with XSLT for several years, and it felt like the worst programming language I had ever seen. For me, the use of code written in XML to process XML felt absurd, and debugging felt next to impossible. I thought it would be nice if someone would create a library in some other programming language (maybe Prolog) that would do the same thing. If it had to first had to "compile" stuff into XSLT, so be it, but programming in XML was so verbose that I had trouble keeping track of my program's structure.
"I thought it would be nice if someone would create a library in some other programming language"
It's just XPath. Grab your favorite programming language, grab XPath, start transforming and outputting. You still probably ought to learn XPath, but unlike XSLT as a whole, learning XPath rather quickly starts paying off.
BTW, I decided I'd see if there was an XPath library for Prolog (once my favorite programming language, and with some conceptual/ algorithmic similarity to XSLT, I think, although XSLT has nothing like Prolog's backtracking). Turns out there is (at least) one: https://www.swi-prolog.org/pldoc/man?predicate=xpath%2f3.
There's a comparison of Prolog and XSLT v1 here: https://arxiv.org/pdf/1912.10817v1 (warning: poorly translated from the Russian original, and dated).
I did know XPath, although I found out the other day that I'd forgotten a lot about it. I was programming in Python using the xml.dom library, which afaict doesn't use XPath at all--I wish it did, I had a very deeply nested set of if-else and for statements to get to something that would have been a single XPath. There's another Python XML library, xml.etree, which provides some ("limited") XPath support, but I had already written most of the code I needed using the dom library when I ran into this.
I will say that for all I'm singing the praises of XPath, the online tutorials and documentation are atrocious. Possibly the worst ratio of quality to library power I've seen. I recently came back to it after a couple of years and couldn't hardly do anything either because I couldn't even reconstruct my previous understanding off of the documentation, but then I consulted my own notes and docs about it and it all came back quickly.
There are two problems. First, everyone is obsessed with trying to label it "declarative" when it is waaaaay better understood as a library for driving around a multicursor imperatively. Call it declarative if you like but I've had way more success driving it effectively imperatively.
Second, each XPath clause has three parts: The "axes", which is the "direction" you want to drive the cursor, the "node selection" which selects which nodes you are talking about (usually the tag name), and then optional filters in [], which can then itself recurse in some ways into further XPath specifications, as well as using some functions and predicates to filter. Fortunately for your convenience, there's a default axis, selecting nodes by tag name is easy, and the filters are indeed optional. Unfortunately for your understanding, there's other defaults and shortcuts and all the "tutorials" and "cheat sheets" and all that jazz teach only the shortcuts, but if you learn only the shortcuts the whole language feels random and very difficult to understand. You really need to learn the full version of the selector clause first, practice by writing it out fully a few times, and then starting to use the shortcuts.
(You can even see the "node selection" as just a type of filter that looks at the tag name most of the time, in which case there are two parts. But it's really confusing when tutorials don't distinguish very well between those two things and mangle it all up into one undifferentiated ball.)
It's not that hard if you are taught it correctly, but I have yet to find something that teaches it correctly online.
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.
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
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.
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.
When they support XSLT 2.0/3.0 in libxml/libxsl, then it will be interesting. Until then, no dice.
XSLT up to 1.1 is a totally different language, actually.
Yup. It's also almost worthless. The fun starts at 2.0.
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.
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…
> 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.
Vogon poetry?
https://www.youtube.com/watch?v=IxPeIiU2kx4
Yes! I thought of equating it with famously bad real-world poetry but it felt mean. I feel ashamed that I didn’t think of vogon poetry.
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/Virsh
https://wiki.gentoo.org/wiki/Virt-manager
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...
Pretty cool to see XSLT mentioned in 2025!
XSLT trending back up?
--
XMLUI
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/ ?)
--
XSLT – Native, zero-config build system for the Web
https://news.ycombinator.com/item?id=44393817 (328 comments; ~month 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/s...
Written as a pipeline of XSLT transformations. Ran natively in the browser to execute SCXML documents to control UI logic. Good times.
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.
Timely. Have an ask from a client and the best solution seems to be XSLT.
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.
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.
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.
>Its predictable, rule-based execution model reduces maintenance effort and makes it easier to onboard new developers into a project
> — when written well
LMAO
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.
> 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.
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
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.
I have prepared my popcorn. Now go, YAML vs. XML vs. JASON vs. TOML vs. ??ML
EDN format is best format: https://github.com/edn-format/edn
That’s close enough to sexprs, the One True Format, that I’ll allow it.
IMO, it’s sexprs on steroids. All the goodness of Lisp sexprs with terse (!) support of useful concepts like vectors, maps, and sets.
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.
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...
yeah just some explicit allowance for associative data (maps)
That's a worthy addition that covers pretty much any use case I'd have.
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.
Akchually YAML is a superset of JASON
Akchually only the YAML JSON (and therefore also the Core) Schema (https://yaml.org/spec/1.2.2/#102-json-schema) is a superset of JSON. The Failsafe Schema is not.