XML Path Language (XPath) 2.0

2.1.1.1 Static Context

The static context of an expression is defined as all information that is available during static analysis of the expression, prior to its evaluation. This information can be used to decide whether the expression contains a static error.

XPath requires the information in the static context to be provided by the language environment in which the expression is being processed. Static context consists of the following components:

• Type exception policy. This is one of the values strict or flexible. The value indicates the action that should be taken when a type exception is raised. If the policy is strict, the error value will be returned. If the policy is flexible, then a fallback conversion will be invoked; the error value will be returned only if the fallback conversion fails.

• In-scope namespaces. This is a set of (prefix, URI) pairs. The in-scope namespaces are used for resolving prefixes used in QNames within the expression.

• Default namespace for element and type names. This is a namespace URI. This namespace is used for any unprefixed QName appearing in a position where an element or type name is expected.

• Default namespace for function names. This is a namespace URI. This namespace is used for any unprefixed QName appearing as the function name in a function call.

• In-scope schema definitions. This is a set of (QName, type definition) pairs. It defines the set of types that are available for reference within the expression. It includes the built-in schema types and all globally-declared types in imported schemas.

• In-scope variables. This is a set of (QName, type) pairs. It defines the set of variables that have been declared and are available for reference within the XPath expression. The QName represents the name of the variable, and the type represents its static data type.

• In-scope functions. This is a set of (QName, function signature) pairs. It defines the set of functions that are available to be called from within the expression. The QName represents the name of the function, and the function signature specifies the static types of the function parameters and function result.

• In-scope collations. This is a set of (URI, collation) pairs. It defines the names of the collations that are available for use in function calls that take a collation name as an argument. A collation may be regarded as an object that supports two functions: a function that given a set of strings, returns a sequence containing those strings in sorted order; and a function that given two strings, returns true if they are considered equal, and false if not.

• Default collation. This is a collation. This collation is used by string comparison functions when no explicit collation is specified.

• Base URI. This is an absolute URI, used by the xf:document function when resolving the relative URI of a document to be loaded, if no explicit base URI is supplied in the function call.

2.1.1.2 Evaluation Context

The evaluation context of an expression is defined as information that is available at the time the expression is evaluated. The evaluation context consists of all the components of the static context, and the additional components listed below.

The first four components of the dynamic context (context item, context position, context size, and context document) are called the focus of the expression. The focus enables the processor to keep track of which nodes are being processed by the expression.

The focus for the outermost expression is supplied by the environment in which the expression is evaluated. Certain language constructs, notably the path expression E1/E2, the filter expression E1[E2], and the ordering expression E1 sortby E2, create a new focus for the evaluation of a sub-expression. In these constructs, E2 is evaluated once for each item in the sequence that results from evaluating E1. Each time E2 is evaluated, it is evaluated with a different focus. The focus for evaluating E2 is referred to below as the inner focus, while the focus for evaluating E1 is referred to as the outer focus. The inner focus exists only while E2 is being evaluated. When this evaluation is complete, evaluation of the containing expression continues with its original focus unchanged. [Ed. Note: See issue 216.]

• The context item is the item currently being processed. An item is either an atomic value or a node. When the context item is a node, it can also be referred to as the context node. The context item is returned by the expression ".". When an expression E1/E2, E1[E2] or E2 sortby E2 is evaluated, each item in the sequence obtained by evaluating E1 becomes the context item in the inner focus for an evaluation of E2.

• The context position is the position of the context item within the sequence of items currently being processed. It changes whenever the context item changes. Its value is always an integer greater than zero. The context position is returned by the expression position(). When an expression E1/E2, E1[E2], or E1 sortby E2 is evaluated, the context position in the inner focus for an evaluation of E2 is the position of the context item in the sequence obtained by evaluating E1. The position of the first item in a sequence is always 1 (one). The context position is always less than or equal to the context size.

• The context size is the number of items in the sequence of items currently being processed. Its value is always an integer greater than zero. The context size is returned by the expression last(). When an expression E1/E2, E1[E2], or E1 sortby E2 is evaluated, the context size in the inner focus for an evaluation of E2 is the number of items in the sequence obtained by evaluating E1.

• The context document is the document currently being processed. Its value is a node, which is always a document node. If there is a context node, and if the tree containing the context node has a document node as its root, then this document node will be the context document. When an inner focus is created and the context item in the inner focus is not a node, or is a node belonging to a tree whose root is not a document node, then the context document in this inner focus will be the same as the context document in the outer focus. The context document is returned by the XPath expression "/", and is used as the base for any rooted path expression, as well being used implicitly by certain functions such as xf:id. [Ed. Note: See Issue 217.]

• Dynamic variables. This is a set of (QName, type, value) triples. It contains the same QNames as the in-scope variables in the static context for the expression. Each QName is associated with the dynamic type and value of the corresponding variable. The dynamic type associated with a variable may be more specific than the static type associated with the same variable. The value of a variable is, in general, a sequence.

  The dynamic types and values of variables are provided by the host language environment in which an XPath expression is being evaluated.

• Current date and time. This information represents a point in time during processing of a query. It can be retrieved by the xf:current-dateTime function. If invoked multiple times during the execution of a query, this function always returns the same result.

• Input sequence. The input sequence is sequence of nodes that can be accessed by the input function. It might be thought of as an "implicit input". The content of the input sequence is determined in an implementation-dependent way.

2.1.1.3 Input Functions

XPath has three functions that provide access to input data. These functions are of particular importance because they provide the only way in which an expression can reference a document or a collection of documents. The three input functions are described informally here, and in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators].

The input sequence is a part of the evaluation context for an expression. The way in which nodes are assigned to the input sequence is implementation-dependent. For instance, one implementation might provide a fixed mapping from a directory system to the input sequence, another implementation might provide a graphical user interface that allows users to choose a data source for the input sequence, and a third implementation might support UNIX-style pipes, allowing the output of one query to become the input sequence for another query.

The input function returns the input sequence. For example, the expression input()//customer returns all the customer elements that are descendants of nodes in the input sequence. If no input sequence has been bound, the input function returns the error value.

The collection function returns the nodes found in a collection. A collection may be any sequence of nodes. A collection is identified by a string, which must be a valid URI. For example, the expression collection("www.example.com/invoices")//customer identifies all the customer elements that are descendants of nodes found in the collection whose URI is www.example.com/invoices.

The document function, when its first argument is a string containing a single URI that refers to an XML document, returns the root of that document. The document function can also be used to address multiple documents or document fragments; see [XQuery 1.0 and XPath 2.0 Functions and Operators] for details.

2.1.2.1 Document Order

Document order defines a total ordering among all the nodes seen by the language processor. Within a given source document, the document node is the first node, followed by element nodes, text nodes, comment nodes, and processing instruction nodes in the order of their representation in the XML document (after expansion of entities). Element nodes occur before their children. The namespace nodes of an element immediately follow the element node, in implementation-defined order. The attribute nodes of an element immediately follow its namespace nodes, and are also in implementation-defined order.

Each input document, and each node or node hierarchy constructed during expression processing, is a separate data model fragment. Document order among data model fragments is implementation-defined but stable within a query.

2.1.2.2 Typed Value

Every node has a typed value, which is a sequence of atomic values. The typed value of any node can be extracted by calling the data function with the node as argument. The typed value for the various kinds of nodes is defined as follows:

1. The typed value of a document, namespace, comment, or processing instruction node is the error value.

2. The typed value of a text node is the string content of the node, as an instance of xs:anySimpleType.

3. The typed value of an element or attribute node that has no type annotation is a sequence of atomic values that is stored in the Data Model.

4. The typed value of an element or attribute node whose type annotation denotes either a simple type or a complex type with simple content is a sequence of atomic values that is obtained by applying the type annotation to the content of the node, as in the following examples:

   • Example: N is an element node of type hatsizelist, which is a complex type that includes a country attribute. The content of the type hatsizelist is a sequence of items of type hatsize, which is derived from xs:decimal. In XML Schema, this content is considered to have a simple type. The typed value of N is a sequence of values of type hatsize.

   • Example: A is an attribute of type IDREFS, a list type derived from IDREF, and its value is "bar baz faz". The typed value of A is a sequence of three atomic values of type IDREF.

5. The typed value of an element node whose type annotation denotes a complex type with complex content is the error value.

2.1.3.1 Type Checking

XPath provides two kinds of type checking, called static type checking and dynamic type checking.

Static type checking is performed during the query analysis phase (also known as "compile time.") Static type checking of an expression is based on the expression itself and on the in-scope schema definitions. Static type checking does not depend on the actual values found in any input document. The purpose of static type checking is to provide early detection of type errors and to compute the type of a query result.

During static type checking, each expression is assigned a static type. In some cases, the static type is derived from the lexical form of the expression; for example, the static type of the literal 5 is xs:integer. In other cases, the static type of an expression is inferred according to rules based on the static types of its operands; for example, the static type of the expression size < 5 is xs:boolean. The static type of an expression may be either a named type or a structural description--for example, xs:boolean? denotes an optional occurrence of the xs:boolean type. The rules for inferring the static types of various expressions are described in [XQuery 1.0 Formal Semantics]. During the analysis phase, if an operand of an expression is found to have a static type that is not appropriate for that operand, a static error is raised. If static type checking raises no errors and assigns a static type T to an expression, then execution of the expression on valid input data is guaranteed to produce either a value of type T or the error value.

Dynamic type checking is performed during the query execution phase (also known as "run time.") Dynamic checking depends on the actual values found in input documents. At run time, a dynamic type is associated with each value as it is computed. The dynamic type of a value may be more specific than the static type of the expression that computed it (for example, the static type of an expression might be "zero or more integers or strings," but at run time its value may have the dynamic type "integer.") If an operand of an expression is found to have a dynamic type that is not appropriate for that operand, a type exception is raised.

The dynamic type of a value may be either a structural type (such as "sequence of integers") or a named type. In many cases, a value that has a structural type can be given a named type by means of a validate expression, which matches the value against known types in the in-scope schema definitions.

It is possible for static type checking of an expression to raise a static type error, even though the expression might evaluate successfully on some valid input data. For example, an expression might contain a function that requires an element as its parameter, and static type checking might infer the static type of the function parameter to be an optional element. In this case, a static type error would result, even though the function call would be successful for input data in which the optional element is present.

It is also possible for an expression to return the error value, even though static type checking of the expression raised no error. For example, an expression may contain a cast of a string into an integer, which is statically valid. However, if the actual value of the string at run time cannot be cast into an integer, the error value will result. Similarly, an expression may apply an arithmetic operator to a value extracted from a schemaless document. This is not a static error, but at run time, if the value cannot be successfully cast to a numeric type, the error value will result.

If an implementation can determine by static analysis that an expression will necessarily return the error value (for example, because it contains a division by the constant zero), the implementation is allowed to report this error at query analysis time (as well as at query execution time).

At user option, static type checking can be disabled. Also, a conformance level may be defined for which implementions need not provide static type checking.

2.1.3.2 SequenceType

When it is necessary to refer to a type in an XPath expression, the syntax shown below is used. This syntax production is called "SequenceType", since it describes the type of an XPath value, which is a sequence.

[48]	SequenceType	::=	(ItemType OccurrenceIndicator) |  "empty"
[49]	ItemType	::=	(("element" |  "attribute") ElemOrAttrType?) |  "node" |  "processing-instruction" |  "comment" |  "text" |  "document" |  "item" |  AtomicType |  "unknown" |  "atomic" "value"
[50]	ElemOrAttrType	::=	SchemaType |  (QName SchemaContext?)
[51]	SchemaType	::=	QName? "of" "type" QName
[45]	SchemaContext	::=	"in" SchemaGlobalContext ("/" SchemaContextStep)*
[46]	SchemaGlobalContext	::=	QName |  ("type" QName)
[47]	SchemaContextStep	::=	QName
[52]	AtomicType	::=	QName
[53]	OccurrenceIndicator	::=	("*" |  "+" |  "?")?

Here are some examples of SequenceTypes that might be used in XPath expressions:

• xs:date refers to the built-in Schema type date

• attribute? refers to an optional attribute

• element refers to any element

• element office:letter refers to an element with a specific name

• element of type po:address+ refers to one or more elements of the given type

• node* refers to a sequence of zero or more nodes of any type

• item* refers to a sequence of zero or more nodes or atomic values

During processing of a query, it is sometimes necessary to determine whether a given value matches a type that was declared using the SequenceType syntax. This process is known as SequenceType matching. For example, an instance of expression returns true if a given value matches a given type, or false if it does not.

SequenceType matching between a given value and a given SequenceType is performed as follows:

If the SequenceType is empty, the match succeeds only if the value is an empty sequence. If the SequenceType is an ItemType with no OccurrenceIndicator, the match succeeds only if the value contains precisely one item and that item matches the ItemType (see below). If the SequenceType contains an ItemType and an OccurrenceIndicator, the match succeeds only if the number of items in the value matches the OccurrenceIndicator and each of these items matches the ItemType. As a consequence of these rules, a value that is an empty sequence matches any SequenceType whose occurrence indicator is * or ?.

An OccurrenceIndicator indicates the number of items in a sequence, as follows:

• ? indicates zero or one items

• * indicates zero or more items

• + indicates one or more items

The process of matching a given item against a given ItemType is performed as follows (remember that an item may be a node or an atomic value):

1. The ItemType item matches any item. For example, item matches the value 1 or the value <a/>.

2. The following ItemTypes match atomic values:

   1. atomic value matches any atomic value.

   2. A named atomic type matches a value if the dynamic type of the value is the same as the named atomic type or is derived from the named atomic type by restriction. For example, the ItemType xs:decimal matches the value 12.34 (a decimal literal); it also matches a value whose dynamic type is shoesize, if shoesize is a user-defined atomic type derived from xs:decimal.

   3. unknown matches an atomic value whose most specific type is xs:anySimpleType.

3. The following ItemTypes match nodes:

   1. node matches any node.

   2. text matches any text node.

   3. processing-instruction matches any processing instruction node.

   4. comment matches any comment node.

   5. document matches any document node.

   6. element matches an element node. Optionally, element may be followed by ElemOrAttrType,which places further constraints on the node (see below).

   7. attribute matches an attribute node. Optionally, attribute may be followed by ElemOrAttrType,which places further constraints on the node (see below).

An ElemOrAttrType may be used to place a constraint on the name or type of an element or attribute, as follows:

1. One form of ElemOrAttrType, denoted by the phrase "of type", specifies the required type of the element or attribute node. The required type must be the QName of a simple or complex type that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has a type annotation that is the same as the required type or is known (in the in-scope schema definitions) to be derived from the required type. For example, element of type Employee matches an element node that has been validated and has received the type annotation Employee. Similarly, attribute of type xs:integer matches an attribute node that has been validated and has received the type annotation xs:integer.

2. Another form of ElemOrAttrType is simply a QName, which is interpreted as the required name of the element or attribute. The QName must be an element or attribute name that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has the required name and also conforms to the schema definition for the required name. This can be verified in either of the following ways:

   1. If the schema definition for the required name has a named type, the given element or attribute must have a type annotation that is the same as that named type or is known (in the in-scope schema definitions) to be derived from that named type. For example, suppose that a schema declares the element named location to have the type State. Then the SequenceType element location will match a given element only if its name is location and its type annotation is State or some named type that is derived from State.

   2. If the schema definition for the required name has an anonymous (unnamed) type definition, the actual content of the given element or attribute must structurally comply with this type definition. For example, suppose that a schema declares the element named shippingAddress to have an anonymous complex type consisting of a street element followed by a city element. Then the SequenceType element shippingAddress will match a given element only if its name is shippingAddress and its content is a street element followed by a city element.

3. The above two forms of ElemOrAttrType may be combined to specify both the required name and the required type of an element or attribute node, as in element person of type Employee or attribute color of type xs:integer.

In some cases, the required name of an element or attribute node may be locally declared (that is, declared inside a complex type in some schema.) In this case, the ElemOrAttrType may specify the SchemaContext in which the required name is to be interpreted. For example, element shippingAddress in invoice/customer matches an element node that conforms to the schema definition of the element name shippingAddress, as it would be interpreted inside a customer element that is inside an invoice element. The first QName in the SchemaContext must be found in the in-scope schema definitions.

[Ed. Note: The effect of substitution groups on SequenceType matching is an open issue.]

2.1.3.3 Type Conversions

Some expressions do not require their operands to exactly match the expected type. For example, function parameters and returns expect a value of a particular type, but allow some basic conversions to be performed, such as extraction of atomic values from nodes, promotion of numeric values, and implicit casting of untyped values. The conversion rules for function parameters and returns are discussed in 2.2.4 Function Calls. Other operators that provide special conversion rules include arithmetic operators, which are discussed in 2.5 Arithmetic Expressions, and value comparisons, which are discussed in 2.6.1 Value Comparisons.

Type conversions sometimes depend on a process called atomization, which is used when an optional atomic value is expected. When atomization is applied to a given value, the result is either a single atomic value, an empty sequence, or a type exception. Atomization is defined as follows:

• If the value is a single atomic value or an empty sequence, atomization simply returns the value.

• If the value is a single node, the typed value of the node is extracted and returned; however, if the typed value is a sequence containing more than one item, a type exception is raised.

• In any other case, atomization raises a type exception.

2.1.3.4 Fallbacks

The action taken when a type exception is raised depends on the language environment in which the XPath expression is being evaluated. A language environment may choose either a strict or a flexible type exception policy. If the policy is strict, a type exception is treated as an error. If the policy is flexible, the language environment must handle type exceptions by applying a fixed set of rules called fallback conversions. The purpose of fallback conversions is to provide backward compatibility with the behavior of XPath Version 1.0.

This means that some language environments may be more permissive than others about type conversions. In general, XPath expressions will be portable from one language environment to another only if they make no reliance on fallback conversions. However, if an expression evaluates without raising an error in two different language environments, it will always return the same result.

A type exception is raised when a given value does not conform to its required type. A language environment that implements fallback conversions must resolve this conflict by applying the following rules, in order:

1. If the required type is anything other than an atomic type or a single node, the error value is returned.

2. If the required type is boolean, and the given value is an empty sequence, the given value is converted to boolean false.

3. If the required type is boolean, and the given value is a sequence containing at least one node, the given value is converted to boolean true.

4. If the required type is a node, and the first item in the sequence is a node, only the first item is retained. If the required type is a node, and the first item in the sequence is not a node, the error value is returned.

5. Otherwise if the given value is a sequence containing more than one item, only the first item is retained. If this item is a node, its typed value is extracted. If the typed value of the node is a sequence of more than one atomic value, only the first of these atomic values is retained. The resulting (supplied or extracted) atomic value is converted to the required type according to the rules in the following table:

   	boolean type	string type	number type	other atomic type
   boolean value	N/A	Boolean false value is converted to the string false. The boolean true value is converted to the string true.	Boolean true is converted to 1; boolean false is converted to 0.	Return the error value
   string value	'true' or '1' goes to true, 'false' or '0' goes to false. Otherwise, if the string is empty, return false; otherwise, return true.	N/A	Use the numeric constructor for the specific number type, passing in the string value.	Use the appropriate string constructor for the specific type as defined in the [XQuery 1.0 and XPath 2.0 Functions and Operators] document.
   number value	0, +0, -0, and NaN, is converted to boolean false, anything else is converted to boolean true.	Use the string value of the atomic value, as defined in the data model.	N/A	Attempt to cast the value to the given atomic type, using the tables defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If a cast cannot be done, return the error value; otherwise a warning should be given.
   other atomic value	Attempt to cast the value to a boolean, using the tables defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If a cast can not be done, return the error value. If precision is lost, a warning should be given.	Attempt to cast the value to a string, using the tables defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If a cast can not be done, return the error value. If precision is lost, a warning should be given.	Attempt to cast the value to a number, using the tables defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If a cast can not be done, return the error value. If precision is lost, a warning should be given.	Attempt to cast the value to the given atomic type, using the tables defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If a cast cannot be done, return the error value; otherwise a warning should be given.

   Ed. Note: The entries in this table should always match the casts in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If there is disagreement, [XQuery 1.0 and XPath 2.0 Functions and Operators] should take precedence.

2.3.1.1 Axes

[26]	ForwardAxis	::=	"child" "::" |  "descendant" "::" |  "attribute" "::" |  "self" "::" |  "descendant-or-self" "::" |  "following-sibling" "::" |  "following" "::" |  "namespace" "::"
[27]	ReverseAxis	::=	"parent" "::" |  "ancestor" "::" |  "preceding-sibling" "::" |  "preceding" "::" |  "ancestor-or-self" "::"

XPath defines a set of full set of axes for traversing documents, but a host language may define a subset of these axes. The following axes are defined:

• the child axis contains the children of the context node

• the descendant axis contains the descendants of the context node; a descendant is a child or a child of a child and so on; thus the descendant axis never contains attribute or namespace nodes

• the parent axis contains the parent of the context node, if there is one

• the ancestor axis contains the ancestors of the context node; the ancestors of the context node consist of the parent of context node and the parent's parent and so on; thus, the ancestor axis will always include the root node, unless the context node is the root node

• the following-sibling axis contains all the following siblings of the context node; if the context node is an attribute node or namespace node, the following-sibling axis is empty

• the preceding-sibling axis contains all the preceding siblings of the context node; if the context node is an attribute node or namespace node, the preceding-sibling axis is empty

• the following axis contains all nodes in the same document as the context node that are after the context node in document order, excluding any descendants and excluding attribute nodes and namespace nodes

• the preceding axis contains all nodes in the same document as the context node that are before the context node in document order, excluding any ancestors and excluding attribute nodes and namespace nodes

• the attribute axis contains the attributes of the context node; the axis will be empty unless the context node is an element

• the namespace axis contains the namespace nodes of the context node; the axis will be empty unless the context node is an element

• the self axis contains just the context node itself

• the descendant-or-self axis contains the context node and the descendants of the context node

• the ancestor-or-self axis contains the context node and the ancestors of the context node; thus, the ancestor-or-self axis will always include the root node

Axes can be categorized as forward axes and reverse axes. An axis that only ever contains the context node or nodes that are after the context node in document order is a forward axis. An axis that only ever contains the context node or nodes that are before the context node in document order is a reverse axis.

In XPath, the parent, ancestor, ancestor-or-self, preceding, and preceding-sibling axes are reverse axes; all other axes are forward axes. Since the self axis always contains at most one node, it makes no difference whether it is a forward or reverse axis. The ancestor, descendant, following, preceding and self axes partition a document (ignoring attribute and namespace nodes): they do not overlap and together they contain all the nodes in the document.

In a sequence of nodes selected by a step, the context positions of the nodes are determined in a way that depends on the axis. If the axis is a forward axis, context positions are assigned to the nodes in document order. If the axis is a reverse axis, context positions are assigned to the nodes in reverse document order. In either case, the first context position is 1.

2.3.1.2 Node Tests

A node test is a condition that must be true for each node selected by a step. The condition may be based on the kind of the node (element, attribute, text, document, comment, processing instruction, or namespace) or on the name of the node.

[28]	NodeTest	::=	KindTest |  NameTest
[29]	NameTest	::=	QName |  Wildcard
[30]	Wildcard	::=	"*" |  ":"? NCName ":" "*" |  "*" ":" NCName
[31]	KindTest	::=	ProcessingInstructionTest |  CommentTest |  TextTest |  AnyKindTest
[32]	ProcessingInstructionTest	::=	"processing-instruction" "(" StringLiteral? ")"
[33]	CommentTest	::=	"comment" "(" ")"
[34]	TextTest	::=	"text" "(" ")"
[35]	AnyKindTest	::=	"node" "(" ")"

Every axis has a principal node kind. If an axis can contain elements, then the principal node kind is element; otherwise, it is the kind of nodes that the axis can contain. Thus:

• For the attribute axis, the principal node kind is attribute.

• For the namespace axis, the principal node kind is namespace.

• For all other axes, the principal node kind is element.

A node test that is a QName is true if and only if the kind of the node is the principal node kind and the expanded-name of the node is equal to the expanded-name specified by the QName. For example, child::para selects the para element children of the context node; if the context node has no para children, it selects an empty set of nodes. attribute::href selects the href attribute of the context node; if the context node has no href attribute, it selects an empty set of nodes.

A QName in a node test is expanded into an expanded-name using the in-scope namespaces in the expression context. An unprefixed QName used as a nametest has the namespaceURI associated with the default element namespace in the expression context. It is an error if the QName has a prefix that does not correspond to any in-scope namespace.

A node test * is true for any node of the principal node kind. For example, child::* will select all element children of the context node, and attribute::* will select all attributes of the context node.

A node test can have the form NCName:*. In this case, the prefix is expanded in the same way as with a QName, using the context namespace declarations. It is an error if there is no namespace declaration for the prefix in the expression context. The node test will be true for any node of the principal node kind whose expanded-name has the namespace URI to which the prefix expands, regardless of the local part of the name.

A node test can also have the form *:NCName. In this case, the node test is true for any node of the principal node kind whose local name matches the given NCName, regardless of its namespace.

The node test text() is true for any text node. For example, child::text() will select the text node children of the context node. Similarly, the node test comment() is true for any comment node, and the node test processing-instruction() is true for any processing instruction. The processing-instruction() test may have an argument that is a StringLiteral; in this case, it is true for any processing instruction whose target application is equal to the value of the StringLiteral.

A node test node() is true for any node whatsoever.

2.3.2.1 Predicates

A predicate consists of an expression, called a predicate expression, enclosed in square brackets. A predicate serves to filter a node sequence, retaining some nodes and discarding others. For each node in the node sequence to be filtered, the predicate expression is evaluated using an inner focus derived from that node, as described in 2.1.1.2 Evaluation Context. The result of the predicate expression is coerced to a Boolean value, called the predicate truth value, as described below. Those nodes for which the predicate truth value is true are retained, and those for which the predicate truth value is false are discarded.

The predicate truth value is derived by applying the following rules, in order:

1. If the value of the predicate expression is an empty sequence, the predicate truth value is false.

2. If the value of the predicate expression is an atomic value of a numeric type, the predicate truth value is true if and only if the value of the predicate expression is equal to the context position.

3. If the value of the predicate expression is an atomic value of type Boolean, the predicate truth value is equal to the value of the predicate expression.

4. If the value of the predicate expression is a sequence that contains at least one node and does not contain any item that is not a node, the predicate truth value is true. The predicate truth value in this case does not depend on the content of the node(s). [Ed. Note: This rule is pending approval by the XSLT Working Group.]

5. In any other case, a type exception is raised.

Here are some examples of steps that contain predicates:

• This example selects the second "chapter" element that is a child of the context node:

  child::chapter[2]

• This example selects all the descendants of the context node whose name is "toy" and whose "color" attribute has the value "red":

  descendant::toy[attribute::color = "red"]

• This example selects all the "employee" children of the context node that have a "secretary" subelement:

  child::employee[secretary]

As noted in 2.2 Primary Expressions, a predicate can also be used with a primary expression that is not a step, as illustrated in the following example:

• List all the integers from 1 to 100 that are divisible by 5.

  (1 to 100)[. mod 5 eq 0]

2.3.2.2 Dereferences

A dereference operates on a node sequence, mapping element and/or attribute nodes into the nodes that they reference. Every node in the input sequence of the dereference must be an element or attribute node whose typed value is of type IDREF or IDREFS; otherwise the error value is returned. The dereference generates a new sequence consisting of the element nodes that are referenced by the IDREF values in the input sequence. An element node is referenced by an IDREF value if it has an ID-type attribute whose value matches the IDREF value, and it is in the same document as the node containing the IDREF value. The referenced nodes are filtered by the NameTest that follows the dereference operator, retaining only nodes whose expanded-names match the expanded-name specified in the NameTest. The filtered sequence of element nodes is then sorted into document order and duplicate node-ids are eliminated.

Here are some examples of steps that contain dereferences:

• This example selects the figure that is referenced by the first figure reference that is a child of the context node:

  child::figref[1]/attribute::refid=>figure

• This example selects the manager of the manager of the context node, assuming that the context node is an emp node and that each emp node has a manager attribute that references the emp node of the employee's manager:

  attribute::manager=>emp/attribute::manager=>emp