
Things XSLT can't do (2012) - Tomte
http://www.dpawson.co.uk/xsl/sect2/nono.html
======
s_gourichon
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/](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.

------
UnoriginalGuy
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...](http://stackoverflow.com/questions/31437121/how-to-output-ampersand-
from-xslt)

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.

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

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

~~~
r00fus
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>

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

------
tannhaeuser
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...](http://www.biglist.com/lists/lists.mulberrytech.com/xsl-
list/archives/199906/msg00270.html)

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

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

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

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

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

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

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

I used CDuce for a significant SOAP project
([http://ocsoap.forge.ocamlcore.org/](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....](http://git.ocamlcore.org/cgi-
bin/gitweb.cgi?p=ocsoap/ocsoap.git;a=blob;f=src/wsdl.cd;h=280aeefed56034f934ad8a4c5b37ce1629068826;hb=HEAD)

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

~~~
rwmj
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](http://www.cduce.org/tutorial_patterns.html)
)

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

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

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

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

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

~~~
paulddraper
[https://cdn.meme.am/instances/500x/65589810.jpg](https://cdn.meme.am/instances/500x/65589810.jpg)

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

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

------
crb002
False. XSLT is Turing complete. Trololololol.

