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

A complete description of the conflict resolution rules, including the role played by the default priority of the pattern, is described under

on page 242 in Chapter 6.

Matching Parentless Nodes

In XSLT 1.0, every node belonged to a tree with a document node at its root. In fact, because the root was always the same kind of node, this kind of node was known as a root node rather than a document node. This has changed in XSLT 2.0: you can now have elements, or even attributes and text nodes, that have no parent. For example, if you write:

then the value of the variable
$seq
is a sequence of three element nodes. These element nodes have no parent, and they are therefore not siblings of each other. The XPath expression
$seq/e
will not select anything, because none of the three nodes in
$seq
has a child element whose name is
e
. If you want to select the
e
element, you should write
$seq[self::e]
(or, if you prefer,
$seq/self::e
).

A tree may thus be rooted at an element node rather than a document node, and this affects the rules for pattern matching. Two consequences of parentless elements complicate the rules.

The first consequence has to do with error handling. In XPath, using an expression such as
/
or
//book
is an error if the context item is in a tree whose root is not a document node. The same applies to the
id()
and
key()
functions. This could mean that if you wrote

, where
$seq
is a sequence of parentless elements, then as soon as the system tried to match it against a template rule specifying

, a runtime error would occur. This would happen, of course, only if the processor took the naive approach of matching every node against every pattern in the stylesheet, and even then only if it took the formal approach of evaluating the equivalent XPath expression. In practice, neither the user nor the implementor would be very happy if this was defined to be an error, so the specification includes a (very ad hoc) rule saying that the system never attempts to match a parentless node against a pattern starting with
/
or
key()
or
id()
, and therefore never hits this error condition.