As a programmer, I am developing programs in procedural and OOP languages for many years now, and I guess I know beautiful and efficient code when I see it (or when I write it).
Recently I started to work with XSLs, and while they deliver the results I expect, I have no idea whether they are nice and beautiful and efficient. (well, they mainly consist of templates and apply-templates, but matching may also hide some performance issues)
So the question is: How do I judge the quality of my XSLs?
It would be better not to use the habits from the OO world, as XSLT is from a different world - functional world. No mutable variables, no normal loops, recursion, lack of side effects... Usually a bit different from what we see in most applications. Thus I would not say that it is that ugly. Just more difficult to read...
One characteristic of "ugly" XSL (or I would say a bad smell in XSL) is over reliance on calling named templates as functions. I've seen this quite often when better use of matches and apply-templates would make a more elegant solution.
XSLT is a pretty powerful language (I think I read once that it is Turing-complete), but you should use it for these situations it is designed for. That includes XML transformations based on pattern matching and XML transformations based on templates.
When you start using XSLT in a procedural manner, it becomes cumbersome and the XML syntax is turning against you. The same holds for string processing or comparison functions.
I have seen excellent results using a combination of XSLT with C# extension functions. Performance has not been a problem for us.
Beauty ~ well-structured, pattern matching templates, recursion. Efficiency ~ avoid complex XPaths
Understanding template matching, especially apply-templates is the number one skill an XSLTer needs to learn. It is impossible to overstate how much XSLT is not like C# or Java or anything OO.
Typical hideousness in XSLT includes:
overuse of xsl:for-each and xsl:call-template
bad, longwinded xpaths (especially ones beginning with "./")
not using keys where suitable
failure to grasp recursion (wrt templates)
thinking of templates as functions
Ask someone else who is an XSL expert. Peer review is a powerful thing if done well.
XSLT is declarative, so performance actually depends on the processors' optimizers. Processors such as Saxon have been evolving for quiet some time, getting more optimization with each release. Also, there are profiles that emulate most popular processors.
You should keep in mind, that there are two ways of processing XML documents. SAX which is a serial parser, very efficient for large documents and in-order transformation. On the other hand DOM which consist of creating a object tree for the whole document, perfect for small documents and transformations completely out-of-order (eg. generating table of contents). So XSLT optimal for one, will not be so for the other.
But as always, time and experience is important...
As far as efficiency goes, in my experience the efficiency of an <xsl:apply-template> generally boils down to three quantities:
To a first (very rough) approximation, the processing required to perform a transform is going to be proportional to the product of those three numbers. Usually inefficiencies come from visiting more nodes in the document than you need to and applying templates to more nodes than you should.
For a crude example, this:
<xsl:apply-templates select="//foo"/>
...
<xsl:template match="foo[bar]">
...
</xsl:template>
<xsl:template match="foo"/>
may be extraordinarily inefficient, especially if the structure of the input document is sufficiently known that it could have been written like this:
<!--
I actually know that foo elements are great-grandchildren of the context node
Also, I'm filtering out foo elements with no bar child at the time I'm building
the node set, and not relying on template matching to do it.
-->
<xsl:apply-templates select="./*/*/foo[bar]" mode="foo_no_bar"/>
...
<!--
I don't have to include a predicate here because I used it in my select, and
I'm using the mode to disambiguating between this and a (possibly) more
generic template for transforming foo elements.
-->
<xsl:template match="foo" mode="foo_no_bar">
...
</xsl:template>
Similarly, it's important not to perform any query more times than you need to. When coding on the fly, it's easy to find yourself writing something like this:
<xsl:if test="foo[@bar='baz']">
<xsl:text>first: </xsl:text>
<xsl:value-of select="foo[@bar='baz']/bat[1]"/>
<xsl:text>second: </xsl:text>
<xsl:value-of select="foo[@bar='baz']/bat[2]"/>
</xsl:if>
when it should be:
<xsl:variable name="list" select="foo[@bar='baz']"/>
<xsl:if test="$list">
<xsl:text>first: </xsl:text>
<xsl:value-of select="$list[1]"/>
<xsl:text>second: </xsl:text>
<xsl:value-of select="$list[2]"/>
</xsl:if>
This is easier to write and maintain, and it also doesn't do more work than it needs to do.
The thing about reasonably well-written XSLT is that it's astonishingly easy to maintain. it doesn't seem like it would be, given how verbose and seemingly cryptic it is. But I regularly find myself making quick changes to 2000-3000 line transforms that I wrote two years ago and having them work properly on the first try. The side-effect-free nature of the language helps a lot.
In addition to the good advice given in many of the previous answers, let me add the following.
One can often find examples of beautiful XSLT code, especially when XSLT is used as a functional programming language.
For examples see this article on FXSL 2.0 -- the Functional Programming library for XSLT 2.0.
As an FP language XSLT is also a declarative language. This, among other things means that one declares, specifies existing relationships.
Such a definition often does not need any additional code to produce a result -- it itself is its own implementation, or an executable definition or executable specification.
Here is a small example.
This XPath 2.0 expression defines the "Maximum Prime Factor of a natural number":
if(f:isPrime($pNum))
then $pNum
else
for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
$vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
$vDiv2 in $pNum idiv $vDiv1
return
max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))
To pronounce it in English, the maximum prime factor of a number pNum is the number itself, if pNum is prime, otherwise if vDiv1 and vDiv2 are two factors of pNum, then the maximum prime factor of pNum is the bigger of the maximum prime factors of vDiv1 and vDiv2.
How do we use this to actually calculate the Maximum Prime Factor in XSLT? We simply wrap up the definition above in an <xsl:function> and ... get the result!
<xsl:function name="f:maxPrimeFactor" as="xs:integer">
<xsl:param name="pNum" as="xs:integer"/>
<xsl:sequence select=
"if(f:isPrime($pNum))
then $pNum
else
for $vEnd in xs:integer(floor(f:sqrt($pNum, 0.1E0))),
$vDiv1 in (2 to $vEnd)[$pNum mod . = 0][1],
$vDiv2 in $pNum idiv $vDiv1
return
max((f:maxPrimeFactor($vDiv1),f:maxPrimeFactor($vDiv2)))
"/>
</xsl:function>
We can, then, calculate the MPF for any natural number, for example:
f:maxPrimeFactor(600851475143) = 6857
As for efficiency, well, this transformation takes just 0.109 sec.
Other examples of both ellegant and efficient XSLT code:
Tim Bray's Wide Finder, as solved here.
Finding all anagrams of a word
Concordance of a text corpus (the Old Testament)
Spelling checking (Shakespear's Othello)
Here are some rules for writing "quality XSLT code", as taken from Mukul Ghandi's blog.
They can be checked/enforced using a tool developed by Mukul:
DontUseDoubleSlashOperatorNearRoot: Avoid using the operator // near the root of a large tree.
DontUseDoubleSlashOperator: Avoid using the operator // in XPath expressions.
SettingValueOfVariableIncorrectly: Assign value to a variable using the 'select' syntax if assigning a string value.
EmptyContentInInstructions: Don't use empty content for instructions like 'xsl:for-each' 'xsl:if' 'xsl:when' etc.
DontUseNodeSetExtension: Don't use node-set extension function if using XSLT 2.0.
RedundantNamespaceDeclarations: There are redundant namespace declarations in the xsl:stylesheet element.
UnusedFunction: Stylesheet functions are unused.
UnusedNamedTemplate: Named templates in stylesheet are unused.
UnusedVariable: Variable is unused in the stylesheet.
UnusedFunctionTemplateParameter: Function or template parameter is unused in the function/template body.
TooManySmallTemplates: Too many low granular templates in the stylesheet (10 or more).
MonolithicDesign: Using a single template/function in the stylesheet. You can modularize the code.
OutputMethodXml: Using the output method 'xml' when generating HTML code.
NotUsingSchemaTypes: The stylesheet is not using any of the built-in Schema types (xs:string etc.), when working in XSLT 2.0 mode.
UsingNameOrLocalNameFunction: Using name() function when local-name() could be appropriate (and vice-versa).
FunctionTemplateComplexity: The function or template's size/complexity is high. There is need for refactoring the code.
NullOutputFromStylesheet: The stylesheet is not generating any useful output. Please relook at the stylesheet logic.
UsingNamespaceAxis: Using the deprecated namespace axis, when working in XSLT 2.0 mode.
CanUseAbbreviatedAxisSpecifier: Using the lengthy axis specifiers like child::, attribute:: or parent::node().
UsingDisableOutputEscaping: Have set the disable-output-escaping attribute to 'yes'. Please relook at the stylesheet logic.
NotCreatingElementCorrectly: Creating an element node using the xsl:element instruction when could have been possible directly.
AreYouConfusingVariableAndNode: You might be confusing a variable reference with a node reference. (contributed by, Alain Benedetti)
IncorrectUseOfBooleanConstants: Incorrectly using the boolean constants as 'true' or 'false'. (contributed by, Tony Lavinio)
ShortNames: Using a single character name for variable/function/template. Use meaningful names for these features.
NameStartsWithNumeric: The variable/function/template name starts with a numeric character