[elmarschraml]

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.

[tjradcliffe]

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.

[jbn]

it's 3 S. "DSSSL" is right.

[phkahler]

>> 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.

[empthought]

It's a reporting engine. There's nothing else besides the "view," and as it is a reporting engine, the view is complex.

[phkahler]

>> 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.

[empthought]

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.

[jerf]

"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.

[Someone1234]

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-...

[FrobeniusTwist]

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."

[JadeNB]

> 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.

[jimfuller2014]

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/

[techdragon]

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.

[bryanrasmussen]

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.

[nordsieck]

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

[gavinpc]

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.

[kyllo]

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?

[Mikhail_Edoshin]

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.

[dharbin]

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.

[michaelsbradley]

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...

[jimfuller2014]

there is an approach in xquery,

which could easily be ported to js

https://github.com/jpcs/transform.xq

[amelius]

isn't this simply solved by functional languages that support pattern matching?