Why I like XSLT(guy-murphy.github.io)
guy-murphy.github.io
Why I like XSLT
https://guy-murphy.github.io/2014/12/02/why-I-like-XSLT/
26 comments
Learning XSLT definitely helped me write much better views in any MVC/MVVM project I have, because the whole approach to template matching is useful as a general design principle. When I'd first started in web development, my views were all very top-down and rife with control logic. After spending considerable time rendering my pages by building XML and applying XSLT, I found a lot of the skills transfer.
Lately I've been working a lot in React, and I've found that just understanding the new syntax can be learned in a weekend -- instead of transforming an XML doc, I load JSON into my state, and instead of writing <xsl:template>s I write React classes. The sort of skills that one refines over years, namely how to think of your rendered page as being composed of various smaller templates, benefit me everywhere. XSLT was a really intensive way to force myself to learn to think that way. Even my mixed PHP/HTML that I occasionally still have to write is considerably better.
to your point about XSLT v1, I can speak to why it's so rarely used at least by PHP devs: v1 has been included as a default extension in PHP builds for many years, but v2 has always required a separate installation of saxon. I just checked on my reasonably up-to-date ubuntu default install, and it's XSLT 1.1.28. That's still far better than Go, where the only approach I've seen is to just install command-line xsltproc and execute that. v2.0 isn't going to catch on while v1.0 is what's considered the de-facto standard, and v1 being the de-facto standard is a big part of why so many have a poor opinion of xslt.
Lately I've been working a lot in React, and I've found that just understanding the new syntax can be learned in a weekend -- instead of transforming an XML doc, I load JSON into my state, and instead of writing <xsl:template>s I write React classes. The sort of skills that one refines over years, namely how to think of your rendered page as being composed of various smaller templates, benefit me everywhere. XSLT was a really intensive way to force myself to learn to think that way. Even my mixed PHP/HTML that I occasionally still have to write is considerably better.
to your point about XSLT v1, I can speak to why it's so rarely used at least by PHP devs: v1 has been included as a default extension in PHP builds for many years, but v2 has always required a separate installation of saxon. I just checked on my reasonably up-to-date ubuntu default install, and it's XSLT 1.1.28. That's still far better than Go, where the only approach I've seen is to just install command-line xsltproc and execute that. v2.0 isn't going to catch on while v1.0 is what's considered the de-facto standard, and v1 being the de-facto standard is a big part of why so many have a poor opinion of xslt.
I don't think learning XSLT made me a better programmer, but it is an amazingly useful tool for dealing with large amounts of XML (which is what it was designed for). That said, the way XPATH works is -- to put it mildly -- counter-intuitive.
My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar as it forces you to reason very carefully about your code, that's probably good practice if you haven't already had plenty of practice -- e.g. developing websites before we had decent browser consoles, or writing INITs and TSRs in the 80s.
My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar as it forces you to reason very carefully about your code, that's probably good practice if you haven't already had plenty of practice -- e.g. developing websites before we had decent browser consoles, or writing INITs and TSRs in the 80s.
We were probably using it for very different things (I used it to render my HTML for a PHP site), but I actually found the debugging part to be a huge advantage of xslt. The errors I had relating to basic config and encoding issues were all big headaches, sure, but debugging issues caused by my own incorrect assumptions about how my data was structured was great -- I never felt lost and every message gave me a clear idea what I needed to look at.
For me XSLT (I mean 2.0 and above) is awesome technology for current web environment. There are a lot of markup languages with which I can for example create graphics (SVG) and use it inside PDF (thru formatting objects (XSL-FO)). I can store complex application configurations inside Excel (OOXML) and transform it to xml and validate it (and then generate data file for db). Or I can manage language translations in excel file and merge them to individual properties files. I can also use powerful XSLT 2.0 inside browser with Saxon-CE. There are really lots of use cases for XSLT. I must mention that I use this technology with Apache ANT and this combination saved a lot of my time! In this way it is possible to do sophisticated automations. I don't know how many people use it but it is possible to have a build file and some xml configuration. In main ant target you specify xslt task (input=xml configuration, output=build file) and subsequent ant task which triggers this generated build file. This technique gives great flexibility! Of course when working with XMLs you need a good IDE!
[deleted]
repost: https://news.ycombinator.com/item?id=8695638 but there was no prior discussion there.
A small number of reposts is OK if the story hasn't received significant attention: https://news.ycombinator.com/newsfaq.html
Ah my apologies, I should have done a better search. Thought it would be worth posting since I have seen it discussed a bit in my area of work [libraries / digital humanities].
xslt really seems to get acceptance from non-programmers who want it to perform a specific functions [like convert some hand crafted xml into html] and hatred from programmers who point out lots of problems with it as a language. I guess I would never even have thought of it as a language until I heard these complaints - I saw it more as a toolkit for, well, performing very specific functions.
xslt really seems to get acceptance from non-programmers who want it to perform a specific functions [like convert some hand crafted xml into html] and hatred from programmers who point out lots of problems with it as a language. I guess I would never even have thought of it as a language until I heard these complaints - I saw it more as a toolkit for, well, performing very specific functions.
No problem. It's good to point out the reposts since it helps identify urls that should be investigated to figure out why the deduping algo didn't catch it.
Good article though.
Good article though.
used a ton of xslt. it's great for what it's good for (transforming xml). of course, if i had to do it all over again i wouldn't be using xml in the first place.
Wow, I never thought I'd see someone say that. I found it to be an endless nightmare when I had to use it. (We thought t would be really cool to store links and other stuff in XML and then transform that into our ASP.NET pages, so we could change the XML file without changing the website. It got complicated over time.)
The point about the syntax is a good one, but I don't like the idea that people should just equivalently like any syntax that expresses the same basic ideas.
I can't say why exactly but something just feels fundamentally wrong with writing code in XML. I felt the same way when I had to write MSBuild scripts, which are XML. I guess it could be trying to do imperative things in a declarative language, but that doesn't seem to be a problem for Lispers.
The point about the syntax is a good one, but I don't like the idea that people should just equivalently like any syntax that expresses the same basic ideas.
I can't say why exactly but something just feels fundamentally wrong with writing code in XML. I felt the same way when I had to write MSBuild scripts, which are XML. I guess it could be trying to do imperative things in a declarative language, but that doesn't seem to be a problem for Lispers.
I need to agree. Using XSLT to write a XML -> HTML website is not a good idea - at least when a bunch of developers maintain it over time.
From the ground up, I admit I like XSLT. But: maintaining large sites that inherit templates (call-templates and apply-templates) and style through <xsl:include/> and <xsl:import/> over lots of files tends to become a template mess. After a while only the experienced devs are able to maintain the templates.
Then, it's a functional language, where lots of things are overly complicated to do; you can do just everything, but that doesn't mean you should.
From the ground up, I admit I like XSLT. But: maintaining large sites that inherit templates (call-templates and apply-templates) and style through <xsl:include/> and <xsl:import/> over lots of files tends to become a template mess. After a while only the experienced devs are able to maintain the templates.
Then, it's a functional language, where lots of things are overly complicated to do; you can do just everything, but that doesn't mean you should.
Why is it a bad idea?
I work together with a bunch of developers on a website that renders its HTML output with XSLT. What you address is architecture.
What we basically did is we have one XSL file for each "element". Elements are: button, image, headline, etc. Each of those elements inputs "our own" XML syntax with wisely chosen defaults (some HTML attributes like class,id,style get just passed through) and outputs Twitter Bootstrap HTML. Writing responsive websites in our framework is extremely easy. So each element has a XSL file where the magic happens, an XML file with documentation and tests and additional files like scass/css/js files with the same name. Accessing them is extremely easy when you use something like Sublime Text (what we all do).
All those different templates get written into just one XSL file automatically with the help of node.js' gulp.
The website gets delivered in Apache Cocoon which has a pipeline concept similar to gulp. Once a page got rendered, it is cached until the next update (except for pages with dynamic content of course).
The whole frameworks documentation is basically a website written in this framework with automated tests.
We use XSLT 1.0 + EXSLT and have written around 30 (EXSLT) functions to make sure everything works like we expect.
Everybody in our team loves it.
I work together with a bunch of developers on a website that renders its HTML output with XSLT. What you address is architecture.
What we basically did is we have one XSL file for each "element". Elements are: button, image, headline, etc. Each of those elements inputs "our own" XML syntax with wisely chosen defaults (some HTML attributes like class,id,style get just passed through) and outputs Twitter Bootstrap HTML. Writing responsive websites in our framework is extremely easy. So each element has a XSL file where the magic happens, an XML file with documentation and tests and additional files like scass/css/js files with the same name. Accessing them is extremely easy when you use something like Sublime Text (what we all do).
All those different templates get written into just one XSL file automatically with the help of node.js' gulp.
The website gets delivered in Apache Cocoon which has a pipeline concept similar to gulp. Once a page got rendered, it is cached until the next update (except for pages with dynamic content of course).
The whole frameworks documentation is basically a website written in this framework with automated tests.
We use XSLT 1.0 + EXSLT and have written around 30 (EXSLT) functions to make sure everything works like we expect.
Everybody in our team loves it.
Probably true; the architecture we had in the team was nonexistant, so it turned into a mess... XSLT then has nothing to improve upon.
If you start out "right", you probably will be able to enjoy XSL.
If you start out "right", you probably will be able to enjoy XSL.
I concur, long time ago I was forced to use XSLT in a business interoperability setting and it was a nightmare when I needed to do any advanced (=competitive) stuff done; it ended up almost as incomprehensible as a multi-stage map-reduce algorithm.
Now for my own e-commerce ETL system I actually had to do a transformation engine encompassing JSON, XML, SQL and NoSQL in Python and rather decided to stick with the KISS principle, allowing declarative stuff for basic simple operations such as multi-key joins and offloading advanced stuff directly to customizable Python scripts.
Now for my own e-commerce ETL system I actually had to do a transformation engine encompassing JSON, XML, SQL and NoSQL in Python and rather decided to stick with the KISS principle, allowing declarative stuff for basic simple operations such as multi-key joins and offloading advanced stuff directly to customizable Python scripts.
> We thought t would be really cool to store links and other stuff in XML and then transform that into our ASP.NET pages
Made my day.
Made my day.
I completely agree; I currently maintain an old web-app that uses xmL/XSLT and it is a complete nightmare to do anything useful.
I used to use it in the browser (IE with MSXML, back in the early/middle part of the last decade) for web apps. XML from the server, XSLT in the browser to generate the UI. You could re-sort, filter, drill-down, etc. all without ever hitting the server again. Just different transforms on the same data. I loved it. Never felt so productive. Rich responsive apps years before JSON and Jquery and all the subsequent JS frameworks started gaining traction.
Syntax is verbose, but felt that the power was worth it. Never found a declarative, functional way to do the same kind of transforms on JSON data, but I'm sure it must exist by now.
Syntax is verbose, but felt that the power was worth it. Never found a declarative, functional way to do the same kind of transforms on JSON data, but I'm sure it must exist by now.
Nothing came close to the speed of XSLT when IE was ruling.
I loved it, and enabled us to build very fast web apps.
But then came JSON, Firefox and other browsers that made XSLT/XML look a less supported and ageing tech.
I tried to write a js equivalent in 2008. And after a couple of iterations it finally ended up with this: http://gitHub.com/pure/pure
It is declarative. With CSS selectors instead of XPATH. Do not mix at all with HTML. And fast rendering.
But then came JSON, Firefox and other browsers that made XSLT/XML look a less supported and ageing tech.
I tried to write a js equivalent in 2008. And after a couple of iterations it finally ended up with this: http://gitHub.com/pure/pure
It is declarative. With CSS selectors instead of XPATH. Do not mix at all with HTML. And fast rendering.
What I like about them the most of the separation. You're actually manipulating the data (XML) and displaying it to end user in HTML without going through the formalities of coding.
Being using them since 1999 too. Still use them today although more work is being done with JSON/JS.
Being using them since 1999 too. Still use them today although more work is being done with JSON/JS.
> What I like about them the most of the separation. You're actually manipulating the data (XML) and displaying it to end user in HTML without going through the formalities of coding.
How is writing XSLT not coding?
How is writing XSLT not coding?
That's it's biggest problem. If you ever had to look at a giant XSLT file and tried to debug some issue, you can understand why it never become popular.
It is. That's the truly awful thing about it - it is a turing complete language that kind of pretends not to be.
This is why templating languages are better at helping you maintain separation of concerns - they physically won't let you put business logic in the view layer because they aren't turing complete. XSLT will.
This is why templating languages are better at helping you maintain separation of concerns - they physically won't let you put business logic in the view layer because they aren't turing complete. XSLT will.
Not being Turing-complete doesn't prevent you from putting business logic in the view layer, it just means that you are likely to run into some limitations doing that (as there are some computable functions that can't be done in the templating language so that you probabaly will run into some business logic that can't be done in it.)
This might further discourage putting business logic in the view layer, but, OTOH, it just as easily result in developers starting to go down the logic-in-view road, running into things that don't work there, and then ending up with some business logic in the view and some business logic in more appropriate layers.
And there's really nothing inherent in view transformations vs. business logic that necessarily makes the latter sufficiently served by a weaker computational model than a Turing complete one, so not having a Turing complete language for the view can result in view transformations in other layers or constrain the flexibility of presentation if that isn't done.
This might further discourage putting business logic in the view layer, but, OTOH, it just as easily result in developers starting to go down the logic-in-view road, running into things that don't work there, and then ending up with some business logic in the view and some business logic in more appropriate layers.
And there's really nothing inherent in view transformations vs. business logic that necessarily makes the latter sufficiently served by a weaker computational model than a Turing complete one, so not having a Turing complete language for the view can result in view transformations in other layers or constrain the flexibility of presentation if that isn't done.
>And there's really nothing inherent in view transformations vs. business logic that necessarily makes the latter sufficiently served by a weaker computational model
There is. View transformations are essentially configuration. As such, the ideal language for describing them is declarative.
To keep declarative languages clear, you need to make them not be turing complete. If they are turing complete they become unpredictable and difficult to understand.
Business logic requires turing completeness and usually requires mutable state.
There is. View transformations are essentially configuration. As such, the ideal language for describing them is declarative.
To keep declarative languages clear, you need to make them not be turing complete. If they are turing complete they become unpredictable and difficult to understand.
Business logic requires turing completeness and usually requires mutable state.
components could be achieved using xslt, you have a high level app spec, and you transform all the components.
The improved syntax is interesting. Are there any better front-ends to XSLT? A quick google turned up SLAX, but I wonder if there are others.
https://github.com/Juniper/libslax
https://github.com/Juniper/libslax
I interned at a company with an XML+XSLT based MVC framework once. I actually thought it worked really well and generally agree with the article. A lot of more "modern" template and transform solutions are aiming for the same goals: sandboxed, side-effect free, limited logic, and so on.
I especially like the power of combining XSLT with Batik and FOP. You can take backend data and present it as an interactive table, a visualization, or a PDF report really easily.
I will say that the syntax is awfully obtuse, though. I find that support for various powerful-but-obtuse 1990s/2000s solution stacks splits along an IDE-user line: those who use IDEs are generally comfortable working with XML and XSLT in Java while text-editor devotees tend to hate that class of solution.
I especially like the power of combining XSLT with Batik and FOP. You can take backend data and present it as an interactive table, a visualization, or a PDF report really easily.
I will say that the syntax is awfully obtuse, though. I find that support for various powerful-but-obtuse 1990s/2000s solution stacks splits along an IDE-user line: those who use IDEs are generally comfortable working with XML and XSLT in Java while text-editor devotees tend to hate that class of solution.
It's not so much obtuse as verbose. It's proof that hell is paved with good intentions: for simple transformations, it feels pretty natural. Unfortunately, once you need something a little more complex, it flies straight into a wall with "XML is not a programming language" written on it. "Function" calls with horribly verbose syntax, etc. Some solutions let you use a real programming language and have the XSL processor trigger your callbacks, but I've never experimented with it.
Alternatively, something Perl's Twig let you manipulate the DOM without too much of a headache, and is preferable to XSLT in many cases.
Alternatively, something Perl's Twig let you manipulate the DOM without too much of a headache, and is preferable to XSLT in many cases.
I got tired of updating my resume in Word then Manually generating PDF and massaging a plain text export into something decent. Now I write one document in ReST that is converted to Docbook (with XSLT) then run the Docbook through XSLT to get the meat of a DocX, XSLT to get an XSL-FO derived PDF, and XSLT to get an HTML derived plain text. Obtuse but powerful.
I get the same results with Markdown and Pandoc. Check it out sometime.
I have a ReST -> rst2html -> wkhtmltopdf pipeline. The advantage is that I can use a standard CSS.
ReST syntax is more sophisticated than even the Pandoc flavor of MD. The ReST parser in Pandoc is very limited and its Docbook output is very restricted as well. It's a nice tool but not there yet for complex documents.
Wow, someone really thought it was a good idea to name something ReST.
I hate to promote my own site (http://theexceptioncatcher.com) but I found that it made it a lot easier to separate the design of the site from the content. Most of my websites rarely ever change, so having a dynamic site is over kill. XSLT/XML helps to keep it as a static site, and I have the opportunity to change/fix the design at will.
Also, I've managed to setup a system to generate my resume via an XML/XSLT transform. I haven't published how I do that (or the public version [which is out of date]).
It's a tool and it can be very useful if you understand what you're doing. Additionally, there is Unix support for XSLT processing.
Also, I've managed to setup a system to generate my resume via an XML/XSLT transform. I haven't published how I do that (or the public version [which is out of date]).
It's a tool and it can be very useful if you understand what you're doing. Additionally, there is Unix support for XSLT processing.
There are _so many_ template engines out there. Using XSLT to generate HTML is one of the most obtuse, obsolete ways you could possibly generate static pages.
https://en.wikipedia.org/wiki/Comparison_of_web_template_eng...
https://en.wikipedia.org/wiki/Comparison_of_web_template_eng...
The problem with a lot of those options is that the transformation happens on the server. I'm not really interested in doing that, with exception to googlebot. I want to keep everything static. It's hard to exploit a website that is all static.
I've used XSLT for APIs that return XML. This allows looking at the output of the API in a human-readable format. This is convenient as a debug tool, and anything that returns an XML page should have a link to the XLST for it.
Alternatively, you could build your API using a human-readable format and dispense with the XSLT. For more complex debugging there's always the Accept header in HTTP which allows you to return a HTML page for browsers using your server-side template engine of choice.
I bought into xslt2... which I think was only ever implimented in the saxon parser, written by they guy that wrote large chunks of the spec. My chain was simple, MS Access DB -> XML (via hand written vba) -> parser -> 4 documents with information that was consistent. I then handed it over to a programmer to replace the Access DB / XML / Parser with the server versions, and he never did get it quite right. For my next project I chose JSON, on the idea that a beautiful solution doesn't mean much if it can't be productionized. Still sad about xslt though, lots of potential for making good looking pdfs and webpages that were consistent.
XSLT is one of those cases where the idea and the intention is great, but the actual implementation is horrible.
I would love to see someone propose a modern alternative to XSLT, that works for the same use cases, but avoids XSLTs mistakes.
I would love to see someone propose a modern alternative to XSLT, that works for the same use cases, but avoids XSLTs mistakes.
Having seen ideas come and go, I think it's more that the problem XSLT sets out to solve--generic tree transformation from XML to anything more-or-less well-formed, with special casing for HTML--is difficult to represent in a clean and sensible way. DSSSL [#] failed. DSSL-O failed. XSLT almost failed.
I use XSLT as part of a reporting engine that generates HTML from fairly complex XML documents on the back end, and whenever I touch it I'm amazed by a) how powerful it is and b) how painful it is to use.
It isn't clear that it's possible to get similar power without similar pain, though, and I think it's beholden on anyone who claims it is to step us and give us an example. A lot of really smart people were involved in DSSSSL and XSLT, and they couldn't solve the problem. Even stripped of the awkward, ugly, syntax, the kind of thing you want to specify in XSLT is complicated and messy.
"Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" is never going to be pretty, and while you can argue that only badly designed document formats require things like "the third element" to be specified, the world we actually live in is full of such things. And because we will always re-purpose document formats to ends their designers never envisaged, it will always be the case.
[#] I can't actually remember how many S's DS*L has in it, although I once did know most of the words to the DSSSL Song.
I use XSLT as part of a reporting engine that generates HTML from fairly complex XML documents on the back end, and whenever I touch it I'm amazed by a) how powerful it is and b) how painful it is to use.
It isn't clear that it's possible to get similar power without similar pain, though, and I think it's beholden on anyone who claims it is to step us and give us an example. A lot of really smart people were involved in DSSSSL and XSLT, and they couldn't solve the problem. Even stripped of the awkward, ugly, syntax, the kind of thing you want to specify in XSLT is complicated and messy.
"Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" is never going to be pretty, and while you can argue that only badly designed document formats require things like "the third element" to be specified, the world we actually live in is full of such things. And because we will always re-purpose document formats to ends their designers never envisaged, it will always be the case.
[#] I can't actually remember how many S's DS*L has in it, although I once did know most of the words to the DSSSL Song.
>> Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" is never going to be pretty
And that is the logic that does not belong in the view. You've failed at properly separating the M,V, and C.
And that is the logic that does not belong in the view. You've failed at properly separating the M,V, and C.
It's a reporting engine. There's nothing else besides the "view," and as it is a reporting engine, the view is complex.
>> It's a reporting engine. There's nothing else besides the "view," and as it is a reporting engine, the view is complex.
The database query is complex. The presentation of data should not be. Mixing these together is a design failure to a lot of people. TFA even mentions this, if you subsequently need to generate a .pdf you're going to embed a redundant copy of the logic in that display code too. If you get the logic down at the lower level where it can be shared, then you can have as many views as need be without duplicating logic that doesn't belong there anyway.
The database query is complex. The presentation of data should not be. Mixing these together is a design failure to a lot of people. TFA even mentions this, if you subsequently need to generate a .pdf you're going to embed a redundant copy of the logic in that display code too. If you get the logic down at the lower level where it can be shared, then you can have as many views as need be without duplicating logic that doesn't belong there anyway.
Nothing about "Emit X when you encounter P except if the third element of type Z (if it exists) of the grandparent of P is a Q with attribute TUESDAY having value FIZBIN emit Q's content transformed according to rule Y" has anything to do with a particular presentation of the data.
What one does is transform different input sources (using XSLT) into a common XML data format, applying stupid rules like the above. Then one applies another transform from the common data format (again using XSLT) to something like HTML, or XSL-FO, or CSV.
"Separation of presentation and query" is really orthogonal to both the use of XSLT and the inevitability of needing to apply complex rules when processing real-world data. XSLT and XPath just happen to be better at expressing those transformations than most other languages, and they certainly have the largest installed base.
What one does is transform different input sources (using XSLT) into a common XML data format, applying stupid rules like the above. Then one applies another transform from the common data format (again using XSLT) to something like HTML, or XSL-FO, or CSV.
"Separation of presentation and query" is really orthogonal to both the use of XSLT and the inevitability of needing to apply complex rules when processing real-world data. XSLT and XPath just happen to be better at expressing those transformations than most other languages, and they certainly have the largest installed base.
it's 3 S. "DSSSL" is right.
"I would love to see someone propose a modern alternative to XSLT, that works for the same use cases, but avoids XSLTs mistakes."
Use an XPath library for your favorite language, and write in your favorite language. XPath is the vast majority of the good in XSL, and there's no reason to put up with the steaming pile of the rest of it just for that bit anymore, and hasn't been for a while.
If XSL hasn't been replaced, well, it's because it's been replaced by too many great languages for doing the same work rather than too few.
Use an XPath library for your favorite language, and write in your favorite language. XPath is the vast majority of the good in XSL, and there's no reason to put up with the steaming pile of the rest of it just for that bit anymore, and hasn't been for a while.
If XSL hasn't been replaced, well, it's because it's been replaced by too many great languages for doing the same work rather than too few.
As someone who has written a lot of XSL I completely agree.
Just having a standard format which is XML-based which is able to take in XML and spit out: different XML, plain text (e.g. CSV, HTML, bespoke UTF-8 formats, etc), and so on is a wonderful idea and XSL does in fact accomplish it.
But, yes, writing XSL is extremely painful. Much of it needlessly so. Although XSL 2 did fix some of my whines (DateTime library?!). I'm still legitimately annoyed (irrationally so) that indexes start at 1 and not 0 in XSL.
The way template matching works is clunky. I think the first answer in this Stackoverflow question illistrates my point well:
https://stackoverflow.com/questions/3127108/xsl-xsltemplate-...
Just having a standard format which is XML-based which is able to take in XML and spit out: different XML, plain text (e.g. CSV, HTML, bespoke UTF-8 formats, etc), and so on is a wonderful idea and XSL does in fact accomplish it.
But, yes, writing XSL is extremely painful. Much of it needlessly so. Although XSL 2 did fix some of my whines (DateTime library?!). I'm still legitimately annoyed (irrationally so) that indexes start at 1 and not 0 in XSL.
The way template matching works is clunky. I think the first answer in this Stackoverflow question illistrates my point well:
https://stackoverflow.com/questions/3127108/xsl-xsltemplate-...
I hear you, but if your assessment is based on XSLT 1.0 (which is likely, since 2.0 was not very widely implemented) you might reconsider. The differences between 1.0 and 2.0 are so stark and significant that they're hardly comparable. They both use the same syntax (XML-based, which is an understandable turn-off), and the processing model is essentially the same, but the inclusion of a real type system in XPath/XSLT 2.0, and some badly-needed features that needed to be kludged in 1.0 (for-each-group being the most conspicuous, IMO) makes a real difference. I think it's a shame that the very real limitations of XSLT 1.0 continue to be imputed to 2.0 (and the impending version 3.0), since, if you're working with XML at all (which maybe you shouldn't be, but that's another issue), XSLT is a great example of Alan Kay's requirement that "simple things should be simple, and complex things should be possible."
> I hear you, but if your assessment is based on XSLT 1.0 (which is likely, since 2.0 was not very widely implemented) you might reconsider.
Are there now any free, portable XSLT 2.0-compatible processors (ideally, that match xsltproc in ease of use)? Surely no-one is comforted by "this version fixes the problems of the previous one, but you can't use it"!
EDIT: OK, Saxon (I won't link to it because I've always felt a little skeeved out by their "let's make people pay for schema awareness" business model, however legitimate it is)—it's even available through MacPorts. I don't know if I just never knew about that, or if the XSLT 2.0 support wasn't always free.
Are there now any free, portable XSLT 2.0-compatible processors (ideally, that match xsltproc in ease of use)? Surely no-one is comforted by "this version fixes the problems of the previous one, but you can't use it"!
EDIT: OK, Saxon (I won't link to it because I've always felt a little skeeved out by their "let's make people pay for schema awareness" business model, however legitimate it is)—it's even available through MacPorts. I don't know if I just never knew about that, or if the XSLT 2.0 support wasn't always free.
here here,
XSLT v1.0 is severely limited and many of the idiosyncratic behaviour ppl associate with XSLT in general is because they hit some very hard to parse/understand/grok things in XSLT v1.0
I remember in 2001-2002 sending the following link, when anyone said 'I am having a problem with XSLT transform'
http://www.exslt.org/exsl/functions/node-set/
XSLT v1.0 is severely limited and many of the idiosyncratic behaviour ppl associate with XSLT in general is because they hit some very hard to parse/understand/grok things in XSLT v1.0
I remember in 2001-2002 sending the following link, when anyone said 'I am having a problem with XSLT transform'
http://www.exslt.org/exsl/functions/node-set/
Thank you for summing it up so well. I was going to write about 2.0 but you've nicely summed it up with the Alan Kay quote.
it's obvious the post is focused on 1.0, the inclusion of the type system in 2.0 really increases the number of sins that can be committed.
Not sure if this is modern, but Steve Yegge makes a good case for swappping angle brackets for parens and using 50 year old tech.
https://sites.google.com/site/steveyegge2/the-emacs-problem
https://sites.google.com/site/steveyegge2/the-emacs-problem
Totally agreed. I'd love to see this in Clojure.
I will stop using XSLT as soon as there is a better way to... transform XML. It is a pure functional language you can use to make web pages, yet it is really automata non grata, if you will, at least to the extent that many people want to kill XML itself.
I wish Microsoft had implemented XSLT 2.0. It seems to me that Michael Kay has almost singlehandedly kept the whole thing alive, but running Saxon in .NET over IKVM (or in Javascript over GWT) is a bit too high a tax for me.
I will stop using XSLT as soon as there is a better way to... transform XML. It is a pure functional language you can use to make web pages, yet it is really automata non grata, if you will, at least to the extent that many people want to kill XML itself.
I wish Microsoft had implemented XSLT 2.0. It seems to me that Michael Kay has almost singlehandedly kept the whole thing alive, but running Saxon in .NET over IKVM (or in Javascript over GWT) is a bit too high a tax for me.
I'd love to see this in Clojure.
What do you mean by that? Can't you just parse XML into a Clojure map, transform it in Clojure, and then emit the result as XML again? Using this: https://github.com/clojure/data.xml
Or did you mean something else?
What do you mean by that? Can't you just parse XML into a Clojure map, transform it in Clojure, and then emit the result as XML again? Using this: https://github.com/clojure/data.xml
Or did you mean something else?
It seems they have a C version of Saxon in the works. Also, I was surprised to learn there's a JavaScript version: Saxon-CE.
Somebody can invent the coffeescript of XSLT! That way, we can keep the compatibility and ubiquity the article talks about, and get the benefit of not writing code-as-XML.
You might find Enlive (a Clojure library) interesting:
https://github.com/cgrand/enlive
See Brian Marick's 5-part tutorial for a good overview:
https://github.com/cgrand/enlive/wiki/Table-and-Layout-Tutor...
https://github.com/cgrand/enlive
See Brian Marick's 5-part tutorial for a good overview:
https://github.com/cgrand/enlive/wiki/Table-and-Layout-Tutor...
there is an approach in xquery,
which could easily be ported to js
https://github.com/jpcs/transform.xq
which could easily be ported to js
https://github.com/jpcs/transform.xq
isn't this simply solved by functional languages that support pattern matching?
XSLT definitely has its flaws and I'm not currently using it, but I am currently building an app whose UI is heavily data-driven, meaning a screen might display a dynamic list of items, each with a totally different editing/viewing/previewing experience. You can dance around the edges of this with current templating engines to the point where you have a workable solution for a specific case, but honestly nothing really compares to the generalizing power of template matching where all you'd need to do is wire up the appropriate XPath selector to a new template and there you go. This level of abstraction does not even appear to be on the radar of the templating libraries I'm familiar with but I'd love to hear about those that do support it if they exist.
So much promise but a clunky abomination imo. I personally wasted a lot of time with it about 10 years ago. I've noticed that technologies that are easier to work with in a text editor eventually win out.
I'm very interested in working on a Javascript framework where you work directly with XML (for data and event binding) and let XSLT handle transforming it to HTML -- imagine React, except you work with XML instead, and treat it as an interface for your HTML.
Email me if you'd like to chat about it!
Email me if you'd like to chat about it!
You can do some interesting things by embedding XSLT and XML into script tags, then wiring them up with MutationObservers -- I just hacked together a quick-and-ugly example of a Knockout-style reactive interface, and it works just fine. The big drawbacks are that your interface is still pretty noisy (though you can preprocess some of those XML headers and CDATA section tags into the page if necessary), and using XPath or DOM functions to update the XML isn't really very fun. Still, though, it'd be interesting to see what could be done with it, even if it's probably not a front end I'd like to wrestle with for daily development.
The cool thing is that jQuery/Sizzle can use normal DOM selectors on an XML document, so there is a little flexibility there, and like you said, MutationObserver is pretty excellent.
Getting rid of the noise is my biggest concern. Ideally, a developer should never have to know about or touch the HTML that's being generated. It's a lofty goal, for sure.
Getting rid of the noise is my biggest concern. Ideally, a developer should never have to know about or touch the HTML that's being generated. It's a lofty goal, for sure.
I guess JSX is a decent start.
ahhh, XSLT, haven't heard that name in awhile.
For my CS honours thesis, I created XSLT debugging program - my research paper is here
http://ww2.cs.mu.oz.au/~jbailey/papers/wise.ps
I miss it :) but now that I'm doing lots of web development & javascript, I do wonder that it is somewhat "slow" or "heavy" than other approaches.
Nonetheless, it was an awesome experience diving deep into the technology.
For my CS honours thesis, I created XSLT debugging program - my research paper is here
http://ww2.cs.mu.oz.au/~jbailey/papers/wise.ps
I miss it :) but now that I'm doing lots of web development & javascript, I do wonder that it is somewhat "slow" or "heavy" than other approaches.
Nonetheless, it was an awesome experience diving deep into the technology.
If I never heard the acronym XSLT again it would be too soon.
First, I don't understand what's with the complaints about the syntax. It's just a flavor of XML. If you work with XML all day, then XSLT looks just fine. But even if you don't like the syntax, so what - there aren't any alternatives to XSLT.
Those of you that know and love XSLT will understand when I say I wish I could be cast into an alternative universe where XSLT continued to be mainstream.
I'll continue to leverage this power-tool (and get paid handsomely by by clients for wielding such power) for the rest of my career.
Those of you that know and love XSLT will understand when I say I wish I could be cast into an alternative universe where XSLT continued to be mainstream.
I'll continue to leverage this power-tool (and get paid handsomely by by clients for wielding such power) for the rest of my career.
>First, I don't understand what's with the complaints about the syntax. It's just a flavor of XML.
People who hate XSLT are not usually fans of XML either.
>But even if you don't like the syntax, so what - there aren't any alternatives to XSLT.
There are hundreds. Simply use any normal programming language (javascript, python, perl, ruby, etc.) with a templating language (handlebars, jinja2, etc.).
The results will be much cleaner, easier to debug, and will remain cleaner as your transformations get ever more complex (code has a habit of doing that).
People who hate XSLT are not usually fans of XML either.
>But even if you don't like the syntax, so what - there aren't any alternatives to XSLT.
There are hundreds. Simply use any normal programming language (javascript, python, perl, ruby, etc.) with a templating language (handlebars, jinja2, etc.).
The results will be much cleaner, easier to debug, and will remain cleaner as your transformations get ever more complex (code has a habit of doing that).
Yep, everyone hates XML and then gets excited over "microformats" or "components" :)
These hundreds of languages have no pattern matching but all have mutable state; XSLT is declarative and this removes a ton of complexity. If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead? Especially as the transformations get more complex?
These hundreds of languages have no pattern matching but all have mutable state; XSLT is declarative and this removes a ton of complexity. If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead? Especially as the transformations get more complex?
>Yep, everyone hates XML and then gets excited over "microformats" or "components" :)
The 'exciting' thing about microformats was that it got you slightly higher positioning in SERPs. I don't know if that's true any longer. That was hardly a benefit of the language design.
I've never heard of components.
>These hundreds of languages have no pattern matching but all have mutable state
There are hundreds of bad languages. I wouldn't defend any of them. Most widely used languages have some form of decent pattern matching, though.
Mutable state can cause headaches, but if you want to use a functional language to help solve that - these days you're spoilt for choice. Most modern languages can be written in a functional style also, if that's your thing.
>XSLT is declarative and this removes a ton of complexity.
The OP made this claim by comparing it favorably to a javascript program that parsed HTML using regular expressions. Which makes me wonder (and shudder about) just what you and the rest of the XSLT defenders are actually comparing it to. And also why you seemingly haven't seen or used any good parsers or templating languages.
>If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead
That would depend entirely upon what I was doing and why. I have done both in different contexts because they had different trade offs.
>Especially as the transformations get more complex?
SQL is capable of handling a great deal of complexity (more than xslt certainly), and its declarative nature certainly nets you a lot of things for free (less code, faster queries, no deserialization/serialization overhead), but it still has its limits. Yes, for really complex transformations I would probably write them in python and not SQL.
The 'exciting' thing about microformats was that it got you slightly higher positioning in SERPs. I don't know if that's true any longer. That was hardly a benefit of the language design.
I've never heard of components.
>These hundreds of languages have no pattern matching but all have mutable state
There are hundreds of bad languages. I wouldn't defend any of them. Most widely used languages have some form of decent pattern matching, though.
Mutable state can cause headaches, but if you want to use a functional language to help solve that - these days you're spoilt for choice. Most modern languages can be written in a functional style also, if that's your thing.
>XSLT is declarative and this removes a ton of complexity.
The OP made this claim by comparing it favorably to a javascript program that parsed HTML using regular expressions. Which makes me wonder (and shudder about) just what you and the rest of the XSLT defenders are actually comparing it to. And also why you seemingly haven't seen or used any good parsers or templating languages.
>If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead
That would depend entirely upon what I was doing and why. I have done both in different contexts because they had different trade offs.
>Especially as the transformations get more complex?
SQL is capable of handling a great deal of complexity (more than xslt certainly), and its declarative nature certainly nets you a lot of things for free (less code, faster queries, no deserialization/serialization overhead), but it still has its limits. Yes, for really complex transformations I would probably write them in python and not SQL.
How could you miss components, the new web revolution? :) Here it is being presented by Google:
https://www.youtube.com/watch?v=2toYLLcoY14
It's basically custom HTML tags like:
I'm talking about pattern matching for templating rules; e.g. I want to handle a "value" token differently depending on whether the parent is a "field" or a "value-list" With XSLT I do this with a pattern: "field/value" vs "value-list/value". It's very clear and very efficient behind the scenes (about as speedy as a regex). I'm not sure I can do it in Python as easily.
As for parsers: parsers are a good thing, certainly, but look at what they do: they take an unstructured sequence of symbols and try to recover the hidden structure of it using a set of grammar rules. The end result is a tree that still contains the original sequence but dissects it into a hierarchy of discovered non-terminals.
Doesn't this look familiar? It's an XML document. XML documents are basically preparsed sequences or serialized parse trees. Maybe they have been parsed already by a specialized parser; or maybe the structure was added there manually when we marked up a text in a natural language; or maybe the sequence was generated by a machine in the first place and we just retained the original structure. What XML does is that it saves the result so there's no need to parse the same sequence again.
(Well, there is; we still need to deserialize the XML document and to interpret certain sequences as strings and another as numbers or dates and this is also parsing; but the serialization notation is much simpler than the grammars that were involved to parse or build the original tree.)
This is why parsing HTML is a waste of time regardless of whether we do this with regular expressions, recursive descent, Earley, LALR, Tomita, PEG, or whatever parsing technology we like :) It has been parsed already; we only need to deserialize it, and this is a trivial task that has been solved long time ago. (Well, maybe not with HTML, because somehow it's important to accept broken HTML and this may require a full-fledged parser and then some.)
https://www.youtube.com/watch?v=2toYLLcoY14
It's basically custom HTML tags like:
<tabs>
<tab>Alpha</tab>
<tab>Bravo</tab>
<tab>Charlie</tab>
</tab>
I'm talking about pattern matching for templating rules; e.g. I want to handle a "value" token differently depending on whether the parent is a "field" or a "value-list" With XSLT I do this with a pattern: "field/value" vs "value-list/value". It's very clear and very efficient behind the scenes (about as speedy as a regex). I'm not sure I can do it in Python as easily.
As for parsers: parsers are a good thing, certainly, but look at what they do: they take an unstructured sequence of symbols and try to recover the hidden structure of it using a set of grammar rules. The end result is a tree that still contains the original sequence but dissects it into a hierarchy of discovered non-terminals.
Doesn't this look familiar? It's an XML document. XML documents are basically preparsed sequences or serialized parse trees. Maybe they have been parsed already by a specialized parser; or maybe the structure was added there manually when we marked up a text in a natural language; or maybe the sequence was generated by a machine in the first place and we just retained the original structure. What XML does is that it saves the result so there's no need to parse the same sequence again.
(Well, there is; we still need to deserialize the XML document and to interpret certain sequences as strings and another as numbers or dates and this is also parsing; but the serialization notation is much simpler than the grammars that were involved to parse or build the original tree.)
This is why parsing HTML is a waste of time regardless of whether we do this with regular expressions, recursive descent, Earley, LALR, Tomita, PEG, or whatever parsing technology we like :) It has been parsed already; we only need to deserialize it, and this is a trivial task that has been solved long time ago. (Well, maybe not with HTML, because somehow it's important to accept broken HTML and this may require a full-fledged parser and then some.)
Agree 100%. I've been using XSLT very extensively in my current role for at least two years now and I love it!
However, I can say with certainty that I'm the only one within my team that shares this view.
Using it for transformation of XML to HTML, semantic validation (does my XML contain A and B when C='Individual'?) and mapping from one XML flavour to something JAXB friendly. Implementing much of this stuff in Java or other would be a nightmare and/or unproductive process with a LOT more code required.
However, I can say with certainty that I'm the only one within my team that shares this view.
Using it for transformation of XML to HTML, semantic validation (does my XML contain A and B when C='Individual'?) and mapping from one XML flavour to something JAXB friendly. Implementing much of this stuff in Java or other would be a nightmare and/or unproductive process with a LOT more code required.
yes, its a typical scenario ... XSLT is one of those languages where people either love it or hate it ... I think its to do with the fact that it takes a bit longer to become productive or useful in XSLT, most developers are expected to just immediately start writing code that 'does stuff' these days.
Anyhow, I see most of developers pain with XSLT is because they never learned the basics of the language and thrash about ... perhaps thats the biggest fault of the language, in that its difficult to tell its story with an analogy to where people start from. Anyhow, learning any fp language tends to improve a developer as a programmer
Anyhow, I see most of developers pain with XSLT is because they never learned the basics of the language and thrash about ... perhaps thats the biggest fault of the language, in that its difficult to tell its story with an analogy to where people start from. Anyhow, learning any fp language tends to improve a developer as a programmer
I'd recently experimented with XSLT for a PHP site's templating engine, after having ignored it since learning it about a decade ago. I swapped out all PHP code to load a bunch of variables for building a big DOMDocument tree in-memory, then applying my XSLT to that to build the rendered HTML. Once I stopped trying to stick a bunch of <xsl:if> and <xsl:for-each>es all over the place, and took a compositional approach to templating where I simply defined the <xsl:template>s I needed and then put <xsl:apply-templates> where I wanted them to go, it actually worked extremely well. All my templates were nicely organized, and I'm far happier working in XML than HTML, with all it's wacky requirements with some tags needing to be closed and others not. It's just the little things that really made me happy -- sticking my fontawesome icons in with an <i class="fa fa-pied-piper" /> instead of <i class="fa fa-pied-piper"></i> always brought a smile to my face. It also made testing nice and fast since it's pretty easy to save the XML I want to transform as a file outside of my PHP app, and just xsltproc it from a terminal until I get it working how I want it.
The big pain points were all around the library support. The XSLT lib was generally fine, but the XML processing PHP provides was rubbish. The main complaint I heard was that even PHP5.5 wouldn't support outputting as html5, and you need to manually just echo out a '<!DOCTYPE html>' to work around that. I couldn't just import HTML directly from elsewhere as rendered by my CMS into my document tree either - it needed to have string literals of tags concatenated to it just to work. The sheer number of piddly little flags that are barely documented but you need to get exactly right in order for it to work at all was a big nuisance too. I also needed to turn off all parser warnings so it wouldn't barf on reading html5 docs, and when a big advantage of the language is that you can be strict about your markup, it seems quite silly to have to turn off warnings.
Looking back on it, none of my problems were really with XSLT as a language, just with how it's implemented in various languages. I feel like a lot of people got turned off when they learned about it in school, and consequently nobody was interested in doing a good job of implementing its supporting libraries in any language.
The big pain points were all around the library support. The XSLT lib was generally fine, but the XML processing PHP provides was rubbish. The main complaint I heard was that even PHP5.5 wouldn't support outputting as html5, and you need to manually just echo out a '<!DOCTYPE html>' to work around that. I couldn't just import HTML directly from elsewhere as rendered by my CMS into my document tree either - it needed to have string literals of tags concatenated to it just to work. The sheer number of piddly little flags that are barely documented but you need to get exactly right in order for it to work at all was a big nuisance too. I also needed to turn off all parser warnings so it wouldn't barf on reading html5 docs, and when a big advantage of the language is that you can be strict about your markup, it seems quite silly to have to turn off warnings.
Looking back on it, none of my problems were really with XSLT as a language, just with how it's implemented in various languages. I feel like a lot of people got turned off when they learned about it in school, and consequently nobody was interested in doing a good job of implementing its supporting libraries in any language.
The opposing viewpoint:
http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of...
Totally agree, XSLT is a great instrument and it can/should be used in a browser too, see http://www.yegor256.com/2014/06/25/xml-and-xslt-in-browser.h...
The following 45 lines of XSL code transforms a simple XML document into XHTML DIV tags that mirror the input structure:
http://djarvis.bitbucket.org/xml/
The pie chart on the following page was also generated using client-side XSLT:
http://djarvis.bitbucket.org/xml/resources.xml
The only "trick" that was required was to load CSS (and some JavaScript) based on the current filename in the URL:
http://djarvis.bitbucket.org/xml/js/common.js
Most people write one XSLT page per web page to transform, but by using structured DIVs with classes that correspond to the XML element names, only one general-purpose XSL page is required.
This demonstrates the separation of content (XML) from presentation (XHTML/CSS).
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
indent="no"
method="html"
doctype-system="about:legacy-compat"
encoding="utf-8"/>
<!-- Action parser that responds to HTTP requests. -->
<xsl:param name="action" select="'do.dhtml'"/>
<xsl:template match="/">
<html>
<head>
<meta charset='utf-8'/>
<title>Title</title>
<link rel='stylesheet' type='text/css' href='css/common.css'/>
</head>
<body>
<xsl:apply-templates/>
<script type='text/javascript' src='js/common.js'></script>
</body>
</html>
</xsl:template>
<!-- Make the document complete with div elements and classes. -->
<xsl:template match="*">
<div class="{local-name()}"><xsl:apply-templates select="node()|@*"/></div>
</xsl:template>
<!-- The 'id' attribute indicates a link. -->
<xsl:template match="*[@id]">
<div class="{local-name()}"><a
href="{$action}?action={local-name()}&id={@id}"><xsl:apply-templates
select="node()|*"/></a></div>
</xsl:template>
<!-- Retain the attributes (except if named "class"). -->
<xsl:template match="@*">
<xsl:if test="name() != 'class'"><xsl:copy-of select="."/></xsl:if>
</xsl:template>
</xsl:stylesheet>
http://djarvis.bitbucket.org/xml/
The pie chart on the following page was also generated using client-side XSLT:
http://djarvis.bitbucket.org/xml/resources.xml
The only "trick" that was required was to load CSS (and some JavaScript) based on the current filename in the URL:
http://djarvis.bitbucket.org/xml/js/common.js
Most people write one XSLT page per web page to transform, but by using structured DIVs with classes that correspond to the XML element names, only one general-purpose XSL page is required.
This demonstrates the separation of content (XML) from presentation (XHTML/CSS).
Give me an input, the expected output, and I will show you I can do a more readable shorter and easier version of the transofrmation with jquery. The XSLT is so unreadable it requires comments.
I did once a less than 2k library in js that loaded the TTML markup in an hidden div and would show it on an HTML 5 video player with extra formatting.
Why would someone need XSLT in 2014? It was a failure in 2000.
I did once a less than 2k library in js that loaded the TTML markup in an hidden div and would show it on an HTML 5 video player with extra formatting.
Why would someone need XSLT in 2014? It was a failure in 2000.
>Benefit #1: Portability
You know that a technology has got serious problems when the best thing you can say about it is "well, it is at least preinstalled everywhere"!
>Benefit #2: Separation of concerns
If you want to put business logic in your XSLT, you can. It is a turing complete language (unlike, say, jinja2).
True, the language is so terrible that you will probably do everything possible to avoid putting business logic in your XSLT and that would help with your separation of concerns. I do not consider this a benefit, however.
>Benefit #3: Transformations
This is not a benefit of the language. This simply what it was originally intended to do.
>Benefit #4: Focus on API: The focus on XML as the result of a controller naturally focuses development on the application API
As opposed to other languages where you don't focus development on the application API?
>Benefit #5: Sand-boxed
Definitely a benefit but far from a unique one. It is also doesn't have particularly good sandbox implementations: https://www.mozilla.org/en-US/security/known-vulnerabilities...
>Benefit #5: Ease of testing
Compared to what?
You know that a technology has got serious problems when the best thing you can say about it is "well, it is at least preinstalled everywhere"!
>Benefit #2: Separation of concerns
If you want to put business logic in your XSLT, you can. It is a turing complete language (unlike, say, jinja2).
True, the language is so terrible that you will probably do everything possible to avoid putting business logic in your XSLT and that would help with your separation of concerns. I do not consider this a benefit, however.
>Benefit #3: Transformations
This is not a benefit of the language. This simply what it was originally intended to do.
>Benefit #4: Focus on API: The focus on XML as the result of a controller naturally focuses development on the application API
As opposed to other languages where you don't focus development on the application API?
>Benefit #5: Sand-boxed
Definitely a benefit but far from a unique one. It is also doesn't have particularly good sandbox implementations: https://www.mozilla.org/en-US/security/known-vulnerabilities...
>Benefit #5: Ease of testing
Compared to what?
>>Benefit #1: Portability
> You know that a technology has got serious problems when the best thing you can say about it is "well, it is at least preinstalled everywhere"!
... plus it's not even true. For any collection of XSL stylesheets, representing any kind of real world complexity, the chances you can port them as-is from A to B is highly dependent on which XSLT features were used (1.0, 2.0 and now 3.0 ), what the XSL processor supports plus "host" framework idiosyncrasies ( Java, .NET, PHP ( http://php.net/manual/en/xsltprocessor.registerphpfunctions.... ! , etc. ).
> You know that a technology has got serious problems when the best thing you can say about it is "well, it is at least preinstalled everywhere"!
... plus it's not even true. For any collection of XSL stylesheets, representing any kind of real world complexity, the chances you can port them as-is from A to B is highly dependent on which XSLT features were used (1.0, 2.0 and now 3.0 ), what the XSL processor supports plus "host" framework idiosyncrasies ( Java, .NET, PHP ( http://php.net/manual/en/xsltprocessor.registerphpfunctions.... ! , etc. ).
> > Benefit #3: Transformations
> This is not a benefit of the language. This simply what it was originally intended to do.
If a technology intends to be good at something, and then is, that's not a benefit of the technology? Huh?
In any case, transformation, i.e. push vs pull templates, is indeed an interesting distinction and feature of XSLT. Using XSLT for push-style problems (like templating a book, a manual, etc.) is where it is actually useful.
> This is not a benefit of the language. This simply what it was originally intended to do.
If a technology intends to be good at something, and then is, that's not a benefit of the technology? Huh?
In any case, transformation, i.e. push vs pull templates, is indeed an interesting distinction and feature of XSLT. Using XSLT for push-style problems (like templating a book, a manual, etc.) is where it is actually useful.
"Ease of testing" is positively hilarious.
One interesting use-case is having an Atom feed and HTML page at the same time. See source code here: https://curiosity-driven.org/
* first bugbear - XSLT is not an implementation of lisp (or insert lang here), we shouldn't care if it implements said language well or not
* XSLT is extremely well (saxon) implemented in some processors and poorly in others ... unsure what that has to do with the language itself.
* XSLT has more implementations then a lot of other popular languages (Ruby, Perl, python come to mind), that doesn't make it better (or worst) then those languages ... its just a fact.
* there are no security vulnerabilities in the design of XSLT that I am aware about (well, there are, and most certainly are in implementations, but at that level I can call out issues with every language and its processor(s)) ... stating it is insecure by design is rubbish
* anyone using XSLT v1.0 should know that there has been, for years, an XSLT v2.0 production ready version in the form of saxon-ce (w/ appropriate open source license) ... I can't explain why folks insist on using XLST v1.0, some are doing so cause they can't migrate to XSLT v2.0, many of them are unaware of new options.
I can understand why folks find XSLT hard, or hurts their brain or makes them want to cringe at the mention of an angle bracket ... teaching basic programming idioms is hard for most people, learning fp principles is even more of a bender (esp if you come from OO world) ... XSLT template matching is a powerful mechanism which allows one to perform transformations with a succinct set of matching rules ... but yes it is verbose and like many languages, XSLT has its ugly points to the language.
If you are allergic to angle brackets, then any language that uses them is going to be anathema to them, but every person I've known who have learned XSLT became a better programmer for it. Thats my own personally biased single data point observed 'fact'.