XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (133 page)

It is sometimes useful to use named modes, even where they are not strictly necessary, to document more clearly the relationship between calling templates and called templates, and to constrain the selection of template rules rather more visibly than can be achieved by relying on template rule priorities. This might even improve performance by reducing the number of rules to be considered, though the effect is likely to be marginal.

For example, suppose that a

consists of a number of

elements, and that the first

is to be output using a different style from the rest. The orthodox way to achieve this would be as follows:

This relies on the default priority rules to ensure that the correct template rule is applied to each stanza—as explained in Chapter 12, the default priority for the pattern
stanza[1]
is higher than the default priority for
stanza
.

Another way of doing this, perhaps less orthodox but equally effective, is as follows:

Another solution, giving even finer control, would be to use

and

to control precisely which template rules are applied to which nodes, avoiding the pattern-matching mechanisms of

altogether.

Which you choose is largely a matter of personal style, and it is very hard to argue that one is better than the other in all cases. However, if you find that the match patterns used in defining a template rule are becoming extremely complex and context dependent, then you probably have both a performance and a maintenance problem on your hands, and controlling the selection of template rules in the calling code, by using modes or by calling templates by name, may well be the answer.

Simulating Higher Order Functions

In functional programming languages, a very useful programming technique is to write a function that accepts another function as an argument. This is known as a higher order function. For example, you might write a function that does a depth-first traversal of a tree and processes each node in the tree using a function that is supplied as an argument. This makes it possible to use one tree-walking routine to achieve many different effects (you might recognize this as the
Visitor Pattern
).

In XSLT (and XPath), functions are not first-class objects, so they cannot be passed as arguments to other functions. The same is true of templates. However, the template-matching capability of

can be used to simulate higher order functions.

This use of

has been developed to a fine art by Dimitre Novatchev in his FXSL library (
http://fxsl.sourceforge.net/
), which provides many examples of the technique.

A simple example of a higher order function found in many functional programming languages is the
fold
function. Given as an argument a function that adds two numbers,
fold
will find the sum of all the numbers in a sequence. Given a function that multiplies two numbers, it will find the product of the numbers in the sequence. In fact,
fold
takes three arguments: the sequence to be processed, the function to process two values, and the initial value. It turns out that the
fold
function can be used, with suitable arguments, to perform a wide variety of aggregation functions on sequences.

The key to the Novatchev technique is that although you cannot pass a function or template as an argument to another function or template, you can pass a node, and you can use

to trigger execution of a template associated with that node.

Rather than show you how
fold
works, which you can find out on the FXSL Web site, I will use another example that makes greater use of the new capabilities in XSLT 2.0. A common problem is to check whether there are cycles in your data. For example, your data might represent a part explosion, and you want to check that no part is a component of itself, directly or indirectly. Or you might be checking an XSLT stylesheet to check that no attribute set is defined in terms of itself. (There is an example that shows how to do this conventionally, without a higher order function, under

on page 344.) The problem is that there are many ways one can represent a relationship between two nodes in XML, and we don't want to have to write a new function to check for cycles each time we come across a new way of representing a relationship. So we write a general higher order function that looks for cycles and pass it, as a parameter, a function (actually represented by a node that will trigger a template rule) that knows how a particular relationship is represented.