An Informal Definition

The formal rules for a pattern such as «book//para » , because they are written in terms of expressions, encourage you to think of the pattern as being evaluated from left to right, which means finding a <book> element and searching for all its <para> descendants to see if one of them is the one you are looking for.

An alternative way of looking at the meaning of this expression, and the way in which most XSLT processors are likely to implement the pattern-matching algorithm, is to start from the right. The actual logic for testing a node against the pattern «book//para » is likely to be along the lines:

• Test whether this is a <para> element. If not, then it doesn't match.

• Test whether there is a <book> ancestor . If not, then it doesn't match.

• Otherwise, it matches.

If there are predicates, these can be tested en route, for example to evaluate the pattern «speech[speaker='Hamlet'] » , the logic is likely to be the following:

• Test whether this is a <speech> element. If not, then it doesn't match.

• Test whether this element has a <speaker> child whose typed value is «Hamlet » . If not, then it doesn't match.

• Otherwise, it matches.

Most patterns can thus be tested by looking only at the node itself and possibly its ancestors , its attributes, and its children. The patterns that are likely to be the most expensive to test are those that involve looking further afield.

For example, consider the pattern «para[last() - 1] » , which matches any <para> element that is the last but one <para> child of its parent. Most XSLT processors, unless they have an exceptionally good optimizer, are going to test whether a particular <para> element matches this pattern by counting how many children the parent element has, counting how many preceding <para> siblings the test <para> has, and comparing the two numbers . Doing this for every <para> element that is processed could get a little expensive, especially if there are hundreds of them with the same parent. With the patterns «para[1] » or «para[last()] » you've a slightly better chance that the processor will figure out a quicker way of doing the test, but it would be unwise to rely on it.

If you write a stylesheet with a lot of template rules, then the time taken to find the particular rule to apply to a given node can make a significant difference. The exact way in which different XSLT processors do the matching may vary, but one thing you can be sure of is that patterns containing complex predicates will add to the cost.