Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
If your stylesheet processes multiple source documents of different types, similar considerations apply. In this case it might be clearer to use explicit namespace prefixes for everything.
See Also
xsl:template
The
Changes in 2.0
It is now possible to define a template rule that matches in multiple modes.
The new
as
attribute allows the type of the result to be defined. Moreover, the new
The syntax for patterns has been extended so that a template rule can now match nodes according to their schema-defined type. The match pattern may also now contain references to global variables or parameters.
Nonsensical combinations of attributes are now considered to be errors; for example, specifying
priority
or
mode
when there is no
match
attribute. In XSLT 1.0, such attributes were ignored.
Format
match? =
pattern
name? =
qname
priority? =
number
mode? =
tokens
as? =
sequence-type
>
Position
Attributes
Name | Value | Meaning |
match optional | Pattern | A pattern that determines which nodes are eligible to be processed by this template. If this attribute is absent, there must be a name attribute. |
name optional | Lexical QName | The name of the template. If this attribute is absent, there must be a match attribute. |
priority optional | Number | A number (positive or negative, integer or decimal) that denotes the priority of this template and is used when several templates match the same node. |
mode optional | Whitespace-separated list of mode names, or #all | The mode or modes to which this template rule applies. When |
as optional | SequenceType | The type of the sequence produced when this template is evaluated. A type error is reported if the result does not match this type. |
The construct
Pattern
is defined in Chapter 12, while
SequenceType
is defined in Chapter 11.
The
mode
and
priority
attributes must not be specified unless the
match
attribute is also specified.
Content
Zero or more
Effect
There must be either a
match
attribute or a
name
attribute, or both.
The match Attribute
The match attribute is a
Pattern
, as defined in Chapter 12. The pattern is used to define which nodes this template rule applies to.
When
A template is only considered a candidate if the node matches the pattern supplied in the
match
attribute and if the value of the
mode
attribute matches the
mode
attribute of the
If more than one template rule meets these criteria, they are first considered in order of import precedence (as described under
If there is still more than one template rule (in other words, if two template rules that both match the node have the same import precedence), they are next considered in order of priority. The priority is either given by the value of the
priority
attribute, described below, or is a default priority that depends on the
match
pattern. The rules for determining the default priority of any pattern are given in Chapter 12, on page 686.
If this leaves one pattern with a numerically higher priority than all the others, this one is chosen. If there are several with the same priority, which is higher than all the others, the XSLT processor has the choice of reporting an error or choosing from the remaining templates the one that appears last in the stylesheet. Several processors in practice report a warning, which you can ignore if you wish. In my experience, however, this condition often indicates that the stylesheet author has overlooked something.
XSLT 2.0 allows the pattern to contain a reference to a global variable or parameter. This allows a pattern such as
match=“part[@number=$param]”
, which means that the same pattern will match different nodes on different runs of the stylesheet. But there are rules to prevent circular definitions: evaluating the variable must not invoke an
There are special rules concerning the handling of errors that occur when matching a node against a pattern. Theoretically, when you execute an
instruction, the processor could evaluate every pattern against the selected nodes. This means that failures can occur if a pattern is inappropriate to the type of node: for example the pattern
B[.=3]
would give a type error when matching an element containing a date. The specification allows the processor to ignore this error and simply treat the pattern as not matching that particular node. This causes few problems in practice, but it creates the danger that real errors go unnoticed. It's best to keep patterns simple enough that runtime errors cannot occur while evaluating them.