Formally Defining Match Patterns

You also can find the definition of match patterns in the W3C XSLT Recommendation. Match patterns are defined in terms of XPath expressions this way:

The syntax for patterns is a subset of the syntax for [XPath] expressions. In particular, location paths that meet certain restrictions can be used as patterns. An expression that is also a pattern always evaluates to an object of type node-set. A node matches a pattern if the node is a member of the result of evaluating the pattern as an expression with respect to some possible context; the possible contexts are those whose context node is the node being matched or one of its ancestors .

The most important sentence in the preceding paragraph is the last one. The idea is that a node X matches a pattern if and only if there is a node that is either X or an ancestor of X, such that when you apply the pattern as an XPath expression to that node, the resulting node set includes X.

So what does that actually mean ? It means that if you want to see whether a pattern matches a node, first apply it to the node itself as an XPath expression, then apply it to all its ancestor nodes in succession, back to the root node. If any node set that results from doing this includes the node itself, the node matches the pattern. Working this way makes sense because match patterns are written to apply to the current node or children of the current node.

Consequences of the Formal Definition of Match Patterns

Defining patterns in terms of XPath expressions this way is relatively straightforward, but now and again there are consequences that arent obvious at first. For example, although the node() function is defined to match any node, when you use it as a pattern, "node()" , its really an abbreviation for "child::node()" , as youll see later in this chapter. Among other things, that means that the pattern "node()" can only match child nodesit will never match the root node. You should also note that there are no patterns that can match namespace-declaration nodes.

The W3C gives the formal definition of match patterns using Extended Backus-Naur Form (EBNF) notation, which is the same notation that the XML specification is written in. You can find an explanation of this grammar at www.w3.org/TR/REC-xml, Section 6. I include the formal definition for patterns here only for the sake of reference. (This whole chapter is devoted to unraveling what this formal definition says and making it clear.) The following list includes the EBNF notations used here:

::= means is defined as
+ means one or more
* means zero or more
means or
means not
? means optional

The following is the actual, formal W3C definition of match patterns; when an item is quoted with single quotation marks, such as 'child' or '::' , that item is meant to appear in the pattern literally (such as "child:: NAME " ), as are items called Literals :

 Pattern  ::= LocationPathPattern  Pattern '' LocationPathPattern  LocationPathPattern ::=  '/' RelativePathPattern?       IdKeyPattern ('/'  '//') RelativePathPattern)?       '//'? RelativePathPattern  IdKeyPattern ::=  'id' '(' Literal ')'   'key' '(' Literal ',' Literal ')'  RelativePathPattern ::=  StepPattern  RelativePathPattern '/' StepPattern       RelativePathPattern '//'     StepPattern  StepPattern ::=  ChildOrAttributeAxisSpecifier NodeTest Predicate*  ChildOrAttributeAxisSpecifier ::=  AbbreviatedAxisSpecifier        ('child'  'attribute') '::'

The definitions for NodeText and Predicate come from the XPath specification as follows (Expr stands for an XPath expression, and NCName and QName were defined at the beginning of Chapter 2, Creating and Using Stylesheets):

 NodeTest ::= NameTest  NodeType '(' ')'  'processing-instruction' '(' Literal ')'  Predicate ::= '[' PredicateExpr ']'  PredicateExpr ::= Expr  AbbreviatedAxisSpecifier ::= '@'?  NameTest ::= '*'  NCName ':' '*'  QName  NodeType ::= 'comment'  'text'  'processing-instruction'  'node'

As you can see, this is all more or less as clear as mud. Now its time to start deciphering. First, a pattern consists of one or more location path patterns . A location path pattern, in turn , consists of one or more step patterns, separated by / or // , or one or more step patterns in conjunction with the id or key functions (which match elements that have specific IDs or keys).

Step patterns are the building blocks of patterns, and you can use multiple steps in a single path, separating them by / or // , as in the pattern "PLANET/*/NAME" , which has three steps: "PLANET" , "*" , and "NAME" . If you start the pattern itself with / , its called absolute , because youre specifying the pattern from the root node (like "/PLANETS/PLANET" or "//PLANET" ); otherwise , its called relative , and its applied starting with the context node (like "PLANET" ).

Next, a step pattern is made up of an axis , a node test , and zero or more predicates . For example, in the expression child::PLANET[position() = 5], child is the name of the axis, PLANET is the node test, and [position() = 5] is a predicate. (Predicates are always enclosed in [ and ] .) You can create patterns with one or more step patterns, such as /child::PLANET/child::NAME , which matches <NAME> elements that are children of a <PLANET> parent.

To understand patterns, then, you have to understand step patterns, because patterns are made up of one or more step patterns in expressions such as "step-pattern1/step-pattern2/step-pattern3..." . And to understand step patterns, you have to understand their three partsaxes, node tests, and predicateswhich Ill take a look at in the following sections.