Things XSLT can't do (2012) | Hacker News Reader

Things XSLT can't do (2012)

dpawson.co.uk

54 pointsTomte25 comments

Much content in this article is interesting, with some caveats.

* The title feels very wrong and may reduce the article content's actual value for people who use XSLT. The good scenario of this title would be: it helps angry people finding the article and if they actually read it they get enlightened. Does it happen?

* A dose of redundancy (dynamic includes for example are repeated a number of times).

* Some issues are genuine limitations, e.g. "Two column table from unsorted data", because "if you want to do further processing on it you have to convert the r-t-f to a node-set" and I've run into that. Solved since.

* Some questions are misleading because asked with a wrong approach, like an instance of the XY problem ( http://xyproblem.info/ ). E.g. "Non well formed HTML input" -> such approach looks like the user actually wants a template mechanism, and instead of that asks for pasting invalid HTML. As written in article, "XSLT is about trees, not tags"... and IMHO that's where it gets a lot of power from!

All in all, this document is interesting, though most value in it is in understanding the spirit and style of XSLT, like "Variables in XSLT have scope based on their appearance in the stylesheet not on runtime behaviour"

If after reading it you understand better what you can do with XSLT (because false paths are now marked in your head, making good paths easier to spot), then it was worth reading.

And for you that read this far: use XSLT for simple things, don't try to pack inside stylesheets issues that don't belong there. Generating ad-hoc XSLT (with whatever tool that can do that well) is fine. Also, since style sheets are XML, generating them with another "upstream" XSLT stylesheet if good, though you have to take care of namespaces. You might think you have to problems instead of one, but they are actually much more doable. KISS and "divide and conquer" principles still apply.

This is an outdated article. Many of the things it claims you cannot do, you can in fact do, you just weren't able to when this was penned.

For example:

http://stackoverflow.com/questions/31437121/how-to-output-am...

Just setting <xsl:output method="text"/> will let you more or less output whatever you want. It doesn't care at that point if the output is valid XML. It is used regularly to convert XML to other text formats using only XSLT.

This article is from 2003. Notably, since then XSLT 2.0, XPath 2.0, and XSLT 3.0 have been released.

Whether unfortunate, or due to design, most/all of these are still valid.

I flagged this article. It needs a [2003] tag to indicate that's it's completely outdated and obsolete.

Unfortunately, it's still valid for the most part. You can't reassign variables, but instead are forced to if-blocks within variable assignments to e.g. assign c node if it exists, otherwise b.

<xsl:variable name="BorC"> <xsl:choose> <xsl:when test="/a/b/c"> <xsl:value-of select="/a/b/c"> </xsl:when> <xsl:otherwise> <xsl:value-of select="/a/b"> </xsl:otherwise> </xsl:choose> </xsl:variable>

XPath 2 supports conditionals so you could put all that in a single select expression.

What XSLT could or couldn't do was already discussed back in 1999 [1]. XSLT was then proven Turing-complete in 2001 [2].

As recently as 2008 (ahem), I implemented a website transforming XML into HTML/DOM using xsl-stylesheet instructions and it worked pretty well on IE6 and FF back then.

But XSLT's Turing-completeness, for me, kind of spelled the death for in-browser XSLT, as XSLT was becoming pointless when you already have JavaScript in the stack.

I don't even know if xsl-stylesheet still works in browsers (supposedly not when using HTML5). But XPath in the browser certainly isn't dead ([3]).

[1]: http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list...

[2]: http://www.unidex.com/turing/utm.htm

[3]: http://www.xmlprague.cz/day2-2017/

> As recently as 2008 (ahem), I implemented a website transforming XML into HTML/DOM using xsl-stylesheet instructions and it worked pretty well on IE6 and FF back then.

Oh ! Me too ! It was based on ATOM and PHP to recreate the files when content was updated.

I did it in 2010, in C. Must have been insane.

As some one who has modernized these apps: screw you guys. That stuff is dying and deserves to die. Yeah, good developers can do elegant things wit it, but for the remaining 90%, well they create layered spaghetti: xsl, html, JavaScript, and that's just the front end. Back end is xml and xsl pipelines with Java/c# intermixed. I've seen business logic in all these layers, in the same api call. It is truly astounding.

This is the double edged sword with XSL as it has enough that it can do that it's hard to tell what you should do at that layer. When it's useful though, it's very useful.

I was very intrigued by XSLT around 2006 but the syntax pained me, and it happend just as I got into a personal lisp mania so I dropped it. I should try it again, after all map, treemap, treereduce is good for your soul.

It's a shame that CDuce is dead, because it's an interesting take on the "XML transformation language" space: http://www.cduce.org

I used CDuce for a significant SOAP project (http://ocsoap.forge.ocamlcore.org/) after a previous negative experience with XSLT. It (CDuce) was a mixed blessing. It was very easy to parse and transform XML, but lacked major features like being able to print debugging information. Also because CDuce couldn't process XML schemas you ended up having to rewrite the schema in CDuce language in your own code. Code example: http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=ocsoap/ocsoap....

I always figured you could get the vast majority of XSLT's benefits without its (numerous) drawbacks by implementing the core match/transform idea in an actual general-purpose expression-oriented language like Haskell or Clojure or Ruby or whatever.

Exactly. CDuce was a noble (but IMHO failed) attempt to add an XML-like DSL with functional-language overtones. For example you could write:

    transform bib with
         <_ (a)> [(x::(Author|Title|Url)|_)*]  ->
             [ <book ({isbn="fake"}+a\year)> x ]

where the <...> syntax looks similar to XML. (This example copied from http://www.cduce.org/tutorial_patterns.html )

We use server-side XSLT at work. We use it as a file based CMS. Our XML is an HTML-abstraction and transforms to Bootstrap. Site has ~12000 single pages.

While I love it, I always wonder if others might think I am crazy.

On HN (ycombinator and all), perhaps it helps to point out that DSSSL, XSLT's precursor, is Scheme-based ([1]).

[1]: https://en.wikipedia.org/wiki/Document_Style_Semantics_and_S...

I don't think your crazy, in fact I've gone looking for such systems in the past while researching static site generators and wanting a more universal solution to let me pull in remote content as xml and json.

I would love to hear more about the system you work with.

We're running XSLT 1.0 on Apache Cocoon.

Within the abstraction, each of our "Elements" has his own XSL stylesheet containing the whole transformation of it. So for developers, it's easy to navigate the code. All elements are compatible with each other.

We've a task running in the background that groups all element into a single XSL stylesheet.

Within Apache Cocoon, you can setup a transformation pipeline. The "elements" will be applied in one step, other steps take care of i18n, i10n and "custom pages"/widgets.

Our documentation is written in that setup, too. We've also setup automated tests for our ~60 custom written EXSLT functions.

This is not really helpful, I took over a reduxulusly huge XSLT project a while ago and just used functions the way you would a variable. Aka do ( x, y) { if (x < 10) { Return do (x+1, x + y * 2) } else return y * 2 + x - 1; }

Stupidly wasteful and kind of a pain for anything complex sure. But, I never found any code I could not write like this.

Several of these (like #2 and #6, and possibly others) can be accomplished by having XSLT generate the XSLT you use to transform the XML.

Cumbersome perhaps, but I've seen this used in a big system, and when properly cached and used in the right circumstances, it performs just as well as a single XSLT.

https://cdn.meme.am/instances/500x/65589810.jpg

I just think of XSLT as something to document XML and make it human-readable. I've used it a few times on things that have an XML API, so that if you look at the output in a browser, it looks better. But it never seemed to be intended for uses much beyond that.

Most of these are by design.

Is there anybody else here who thinks that DSSSL was a nicer language than XSLT? Mind, it couldn't do most of these things either, but it was basically functional Scheme. And I'll take Scheme over... whatever XSLT is any day.

False. XSLT is Turing complete. Trololololol.

Reply on news.ycombinator.com