XQuery 1.0: An XML Query Language

2.1.1 Static Context

The static context of an expression is the 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.

In XQuery, the information in the static context is provided by declarations in the Query Prolog (except as noted below). Static context consists of the following components:

• 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. It may also include types declared in schemas associated with documents retrieved by input functions, as described in 2.2 Input Functions.

  Ed. Note: The importing of type definitions from input documents is still under discussion. The idea that the static context should be affected by run-time functions in an implementation-defined way remains controversial (see Issue 307.)

• 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 expression. The QName represents the name of the variable, and the type represents its static data type.

  Unlike the other parts of the static context, variable types are not declared in the Query Prolog. Instead, they are derived from static analysis of the expressions in which the variables are bound.

• In-scope functions. This part of the static context defines the set of functions that are available to be called from within an expression. Each function is uniquely identified by its QName and its arity (number of parameters). The static context maps QName and arity into a function signature, which 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.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 three components of the dynamic context (context item, context position, and context size) 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 predicate expression E1[E2], and the ordering expression E1 sort by (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 sort by (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 xf:position(). When an expression E1/E2, E1[E2], or E1 sort by (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 sort by (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.

• 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 the value of 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 execution of the XQuery expressions in which the variables are bound.

• Current date and time. This information represents an implementation-defined point in time during processing of a query or transformation. It can be retrieved by the xf:current-date, xf:current-time, and xf:current-dateTime functions. If invoked multiple times during the execution of a query or transformation, these functions always returns a consistent result.

• Implicit timezone. This is the timezone to be used when a date, time, or dateTime value that does not have a timezone is used in a comparison or in any other operation. This value is an instance of dayTimeDuration that is implementation-defined. See [ISO 8601] for the range of legal values of a timezone.

• 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-defined way.

2.3.1 Document Order

Document order defines a total ordering among all the nodes seen by the language processor. Within a given 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 form of the 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.

The relative order of nodes in distinct documents is implementation-defined but stable within a given query or transformation. In other words, given two distinct documents A and B, if a node in document A is before a node in document B, then every node in document A is before every node in document B. The relative order among free-floating nodes (those not in a document) is implementation-defined.

2.3.2 Typed Value and String Value

Element, attribute, and text nodes have a typed value and a string value that can be extracted by calling the data function and the string function, respectively. The typed value of a node is a sequence of atomic values, and the string value of a node is a string. Element and attribute nodes also have a type annotation, which is a QName that is defined in the in-scope schema definitions. The type annotation of a node is assigned when the node is constructed, and can be changed by validating the node (see 3.13 Validate Expressions).

The typed value and string value for each kind of node are defined by the dm:typed-value and dm:string-value accessors in [XQuery 1.0 and XPath 2.0 Data Model]. Specifically:

1. The typed value of a text node is the same as its string value, as an instance of xs:anySimpleType.

2. If the type annotation of an attribute node is xs:anySimpleType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model].

   • Example: A1 is an unvalidated attribute whose content is defined by the expression {2 + 2}. The type annotation of A1 is xs:anySimpleType. The string value of A1 is "4". The typed value of A1 is "4" as an instance of xs:anySimpleType. If A1 is later validated and found to have the type hatsize, its string value is still "4", but its typed value is 4 as an instance of hatsize.

   • Example: A2 is a validated attribute with type annotation IDREFS, which is a list type derived from IDREF. Its string value is "bar baz faz". The typed value of A2 is a sequence of three atomic values ("bar", "baz", "faz"), each of type IDREF.

3. If the type annotation of an element node is xs:anyType, its typed value is equal to its string value, as an instance of xs:anySimpleType. Otherwise, its typed value is derived from its string value and type annotation in a way that is consistent with schema validation, as described in [XQuery 1.0 and XPath 2.0 Data Model]. If the type annotation of an element denotes a type with complex content (i.e., a type that permits subelements), its typed value is undefined, and the data function raises an error when applied to such an element.

   • Example: E1 is an unvalidated element node whose content is defined by the expression {1, 2, 3}. The type annotation of E1 is xs:anyType. The string value of E1 is the string "1 2 3". The typed value of E1 is "1 2 3" as an instance of xs:anySimpleType.

   • Example: E2 is a validated element node with the type annotation hatsizelist, which is a complex type whose content is defined as a sequence of items of type hatsize, which in turn is derived from xs:integer. The string value of E2 is "7 8 9". The typed value of E2 is a sequence of three values (7, 8, 9), each of type hatsize.

   • Example: E3 is a validated element node with the type annotation weather, which is a complex type that permits subelements. The string value of E3 is "hot". Even though E3 does not happen to contain any subelements, its typed value is undefined because its type permits subelements.

2.4.1 Type Checking

XQuery defines two phases of processing called the analysis phase and the evaluation phase.

The analysis phase depends on the query expression itself and on the static context. The analysis phase does not depend on any input data. The purpose of type-checking during the analysis phase is to provide early detection of type errors and to compute the type of a query result.

During the analysis phase, 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 type 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 to raise a dynamic type error.

The evaluation phase is performed only after successful completion of the analysis phase. The evaluation phase depends on input data, on the expression being evaluated, and on the evaluation context. During the evaluation phase, a dynamic type is associated with each value as it is computed. The dynamic type of a value may be either a structural type (such as "sequence of integers") or a named type. 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.

It is possible for analysis 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 the analysis phase 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 raise a dynamic error, even though analysis of the expression raised no static 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, a dynamic error 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, a dynamic error will be raised.

If an implementation can determine by static analysis that an expression will necessarily raise a dynamic error (for example, because it attempts to construct a decimal value from a constrant string that is not a valid decimal value), the implementation is allowed to report this error during the analysis phase (as well as during the evaluation phase).

2.4.2 SequenceType

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

Here are some examples of SequenceTypes that might be used in XQuery expressions or function parameters:

• 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 that has a specific name and that has been validated as conforming to the schema definition for that name

• element of type po:address+ refers to one or more elements that have been validated as conforming to the schema definition 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 atomic value 1 or the element <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 an atomic type derived from xs:decimal.

   3. untyped 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.

   The constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].

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. This form might be used, for example, to specify a required type that is more specific than the schema type associated with the required name.

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.

2.4.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 automatically perform certain type conversions, 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 3.1.4 Function Calls. Other operators that provide special conversion rules include arithmetic operators, which are discussed in 3.4 Arithmetic Expressions, and value comparisons, which are discussed in 3.5.1 Value Comparisons.

2.5.1 Errors

As described in 2.4.1 Type Checking, XQuery defines an analysis phase, which does not depend on input data, and an evaluation phase, which does depend on input data.

The result of the analysis phase is either success or one or more static errors. Some static errors are static type errors, which occur when the static type of an expression is not correct for the context in which it appears. The term static errors also includes non-type-related errors such as syntax errors. The means by which static errors are reported is implementation-defined.

The result of the evaluation phase is either a result value or a dynamic error. Some dynamic errors are dynamic type errors, which occur when the dynamic type of an expression is not correct for the context in which it appears. The term dynamic errors also includes non-type-related dynamic errors such as numeric overflow. If an implementation returns a value, the value must conform to the dynamic rules defined in [XQuery 1.0 Formal Semantics].

[XQuery 1.0 Formal Semantics] defines the set of static and dynamic errors. In addition to these errors, an XQuery implementation may raise implementation-defined warnings, either during the analysis phase or the evaluation phase. The way in which warnings are raised and handled is implementation-defined.

2.5.2 Conformance

XQuery defines a basic conformance level named Basic XQuery, and two optional features called the Schema Import Feature and the Static Typing Feature. A conforming implementation must satisfy the requirements of Basic XQuery, and may also provide either or both of the optional features.

2.5.3 Handling Dynamic Errors

Except as noted in this document, if any operand of an expression raises a dynamic error, the expression also raises a dynamic error. If an expression can validly return a value or raise a dynamic error, the implementation may choose to return the value or raise the dynamic error. For example, the logical expression expr1 and expr2 may return the value false if either operand returns false, or may raise a dynamic error if either operand raises a dynamic error.

If more than one operand of an expression may raise an error, the implementation may choose which error is raised by the expression. For example, in this expression:

($x div $y) + xsd:decimal($z)

both ($x div $y) and xsd:decimal($z) may raise an error. The implementation may choose which error is raised by the "+" expression. Once one operand raises an error, the implementation is not required, but is permitted, to evaluate any other operands.

A dynamic error carries an error value, which may be a single item or an empty sequence. For example, an error value might be an integer, a string, a QName, or an element. An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostics; in the absence of such an error handler, the string-value of the error value may be used directly as an error message.

A dynamic error may be raised by a built-in function or operator. For example, the input function raises an error if the input sequence is not defined in the evaluation context.

An error can be raised explicitly by calling the xf:error function, which only raises an error and never returns a value. The xf:error function takes an optional item as its parameter, which is used as the error value. For example, the following function call raises a dynamic error whose error value is a string:

xf:error(xf:concat("Unexpected value ", $v))

3.1.1 Literals

A literal is a direct syntactic representation of an atomic value. XQuery supports two kinds of literals: string literals and numeric literals.

The value of a string literal is a singleton sequence containing an item whose primitive type is xs:string and whose value is the string denoted by the characters between the delimiting quotation marks. If the literal is delimited by single quotes, two adjacent single quote characters within the literal are interpreted as one single quote character. Similarly, if the literal is delimited by double quotes, two adjacent double quote characters within the literal are interpreted as one double quote character.

The value of a numeric literal containing no "." and no e or E character is a singleton sequence containing an item whose type is xs:integer and whose value is obtained by parsing the numeric literal according to the rules of the xs:integer datatype. The value of a numeric literal containing "." but no e or E character is a singleton sequence containing an item whose primitive type is xs:decimal and whose value is obtained by parsing the numeric literal according to the rules of the xs:decimal datatype. The value of a numeric literal containing an e or E character is a singleton sequence containing an item whose primitive type is xs:double and whose value is obtained by parsing the numeric literal according to the rules of the xs:double datatype.

Here are some examples of literal expressions:

• "12.5" denotes the string containing the characters '1', '2', '.', and '5'.

• 12 denotes the integer value twelve.

• 12.5 denotes the decimal value twelve and one half.

• 125E2 denotes the double value twelve thousand, five hundred.

The boolean values true and false can be represented by calls to the built-in functions xf:true() and xf:false(), respectively.

Values of other XML Schema built-in types can be constructed by calling the constructor for the given type. The constructors for XML Schema built-in types are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. In general, the name of a constructor function for a given type is the same as the name of the type (including its namespace). For example:

• xs:integer("12") returns the integer value twelve.

• xs:date("2001-08-25") returns an item whose type is xs:date and whose value represents the date 25th August 2001.

• xf:dayTimeDuration("PT5H") returns an item whose type is xf:dayTimeDuration and whose value represents a duration of five hours.

It is also possible to construct values of various types by using a cast expression. For example:

• cast as hatsize(9) returns an item whose primitive value is the integer 9 and whose type is the user-defined type hatsize, derived from xs:integer.

3.1.2 Variables

A variable evaluates to the value to which its name is bound in the evaluation context. An expression containing an unbound variable raises a static error. Variables can be bound by clauses in for expressions and quantified expressions, and by function calls, which bind values to the formal parameters of functions before executing the function body.

3.1.3 Parenthesized Expressions

Parentheses may be used to enforce a particular evaluation order in expressions that contain multiple operators. For example, the expression (2 + 4) * 5 evaluates to thirty, since the parenthesized expression (2 + 4) is evaluated first and its result is multiplied by five. Without parentheses, the expression 2 + 4 * 5 evaluates to twenty-two, because the multiplication operator has higher precedence than the addition operator.

Empty parentheses are used to denote an empty sequence, as described in 3.3.1 Constructing Sequences.

3.1.4 Function Calls

A function call consists of a QName followed by a parenthesized list of zero or more expressions, called arguments. The QName and number of arguments must match the name and arity of an in-scope function in the static context (see 2.1 Expression Context); otherwise, a static error is raised.

A function call expression is evaluated as follows:

1. Each argument expression is evaluated, producing an argument value.

2. Each argument value is converted to the declared type of the corresponding function parameter, using the function conversion rules listed below.

3. If the function is a built-in function, it is executed using the converted argument values. The result is a value of the function's declared return type.

4. If the function is a user-defined function, the converted argument values are bound to the formal parameters of the function, and the function body is evaluated. The value returned by the function body is then converted to the declared return type of the function by applying the function conversion rules.

   A function does not inherit a focus (context item, context position, and context size) from the environment of the function call. During evaluation of a function body, the focus is undefined, except where it is defined by the action of some expression inside the function body. Use of an expression that depends on the focus when the focus is undefined results in a dynamic error.

The function conversion rules are used to convert an argument value or a return value to its required type; that is, to the declared type of the function parameter or return. The required type is expressed as a SequenceType. The function conversion rules are as follows:

1. If the required type is an AtomicType:

   Atomization is applied to the given value. If the resulting atomic value is of type xs:anySimpleType, an attempt is made to cast it to the required type; if the cast fails, the function call raises a dynamic type error. If the atomic value has a type that can be promoted to the required type using the promotion rules in B.1 Type Promotion, the promotion is done.

2. If the required type is a sequence or optional occurrence of AtomicType:

   If the given value contains any nodes, these nodes are replaced by their typed values. Each item is converted to the required AtomicType using the conversion rule for AtomicType.

3. If the required type is any other SequenceType, or if no required type is declared:

   No conversion is performed.

If the Static Typing Feature is implemented, and the static type of a (converted) function argument or result, as inferred by the static type inference rules in [XQuery 1.0 Formal Semantics], is not a subtype of the required type, a static type error is raised. If the Static Typing Feature is not implemented, and the dynamic type of a (converted) function argument or result does not match the required type according to the rules for SequenceType Matching, a dynamic type error is raised.

A core library of functions is defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]. Functions in this library may be invoked without a namespace prefix by assigning the default function namespace to the namespace of the function library.

The comma operator in XQuery serves two purposes: it separates the arguments in a function call, and it separates items in an expression that constructs a sequence (see 3.3.1 Constructing Sequences). To distinguish these two uses, parentheses can be used to delimit the individual arguments of a function call. Here are some illustrative examples of function calls:

• three-argument-function(1, 2, 3) denotes a function call with three arguments.

• two-argument-function((1, 2), 3) denotes a function call with two arguments, the first of which is a sequence of two values.

• two-argument-function(1, ()) denotes a function call with two arguments, the second of which is an empty sequence.

• one-argument-function((1, 2, 3)) denotes a function call with one argument that is a sequence of three values.

• one-argument-function(( )) denotes a function call with one argument that is an empty sequence.

• zero-argument-function( ) denotes a function call with zero arguments.

3.1.5 Comments

XQuery comments can be used to provide informative annotation. These comments are lexical constructs only, and do not affect the processing of an expression.

Comments may be used before and after major tokens within expressions and within element content. See A.1 Lexical structure for the exact lexical states where comments are recognized.

The following is an example of a comment:

{-- Houston, we have a problem --}

Ed. Note: The EBNF should disallow "--}" within the comment, rather than "}". Also, within an enclosed expression, a comment immediately after the opening "{" will cause the "{{" to be mistaken for an escaped "{". Thus, <a>{{--comment--}foo}</a> will currently cause an error, and must be disambiguated with a space between the "{" characters. This should be considered an open issue.

3.2.1 Steps

A step generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates. Predicates are described in 3.2.2 Predicates.

A step may consist of a primary expression (described in 3.1 Primary Expressions), a forward step, or a reverse step. A forward or reverse step always returns a sequence of nodes. A forward or reverse step might be thought of as beginning at the context node and navigating to those nodes that are reachable from the context node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which specifies the node kind and/or name of the nodes to be selected by the step.

In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 3.2.4 Abbreviated Syntax.

The unabbreviated syntax for a forward or reverse step consists of the axis name and node test separated by a double colon. The result of the step consists of the nodes reachable from the context node via the specified axis that have the node kind and/or name specified by the node test. For example, the step child::para selects the para element children of the context node: child is the name of the axis, and para is the name of the element nodes to be selected on this axis. The available axes are described in 3.2.1.1 Axes. The available node tests are described in 3.2.1.2 Node Tests. Examples of steps are provided in 3.2.3 Unabbreviated Syntax and 3.2.4 Abbreviated Syntax.

3.2.2 Predicates

A predicate consists of an expression, called a predicate expression, enclosed in square brackets. A predicate serves to filter a sequence, retaining some items and discarding others. For each item in the sequence to be filtered, the predicate expression is evaluated using an inner focus derived from that item, as described in 2.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 items 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, the predicate truth value is true. The predicate truth value in this case does not depend on the content of the node(s).

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]

A predicate can also be used with a primary expression that is not a forward or reverse step, as illustrated in the following example:

• List all the integers from 1 to 100 that are divisible by 5. (See 3.3.1 Constructing Sequences for an explanation of the to operator.)

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

3.2.3 Unabbreviated Syntax

This section provides a number of examples of path expressions in which the axis is explicitly specified in each step. The syntax used in these examples is called the unabbreviated syntax. In many common cases, it is possible to write path expressions more concisely using an abbreviated syntax, as explained in 3.2.4 Abbreviated Syntax.

• child::para selects the para element children of the context node

• child::* selects all element children of the context node

• child::text() selects all text node children of the context node

• child::node() selects all the children of the context node, whatever their node type

• attribute::name selects the name attribute of the context node

• attribute::* selects all the attributes of the context node

• descendant::para selects the para element descendants of the context node

• descendant-or-self::para selects the para element descendants of the context node and, if the context node is a para element, the context node as well

• self::para selects the context node if it is a para element, and otherwise selects nothing

• child::chapter/descendant::para selects the para element descendants of the chapter element children of the context node

• child::*/child::para selects all para grandchildren of the context node

• / selects the root of the node hierarchy that contains the context node

• /descendant::para selects all the para elements in the same document as the context node

• /descendant::list/child::member selects all the member elements that have an list parent and that are in the same document as the context node

• child::para[xf:position() = 1] selects the first para child of the context node

• child::para[xf:position() = xf:last()] selects the last para child of the context node

• child::para[xf:position() = xf:last()-1] selects the last but one para child of the context node

• child::para[xf:position() > 1] selects all the para children of the context node other than the first para child of the context node

• /descendant::figure[xf:position() = 42] selects the forty-second figure element in the document

• /child::doc/child::chapter[xf:position() = 5]/child::section[xf:position() = 2]selects the second section of the fifth chapter of the doc document element

• child::para[attribute::type="warning"]selects all para children of the context node that have a type attribute with value warning

• child::para[attribute::type='warning'][xf:position() = 5]selects the fifth para child of the context node that has a type attribute with value warning

• child::para[xf:position() = 5][attribute::type="warning"]selects the fifth para child of the context node if that child has a type attribute with value warning

• child::chapter[child::title='Introduction']selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

• child::chapter[child::title] selects the chapter children of the context node that have one or more title children

• child::*[self::chapter or self::appendix] selects the chapter and appendix children of the context node

• child::*[self::chapter or self::appendix][xf:position() = xf:last()] selects the last chapter or appendix child of the context node

3.2.4 Abbreviated Syntax

The abbreviated syntax permits the following abbreviations:

1. The most important abbreviation is that child:: can be omitted from a step. In effect, child is the default axis. For example, a path expression section/para is short for child::section/child::para.

2. There is also an abbreviation for attributes: attribute:: can be abbreviated by @. For example, a path expression para[@type="warning"] is short for child::para[attribute::type="warning"] and so selects para children with a type attribute with value equal to warning.

3. // is short for /descendant-or-self::node()/. For example, //para is short for /descendant-or-self::node()/child::para and so will select any para element in the document (even a para element that is a document element will be selected by //para since the document element node is a child of the root node); div1//para is short for div1/descendant-or-self::node()/child::para and so will select all para descendants of div1 children.

   Note that the path expression //para[1] does not mean the same as the path expression /descendant::para[1]. The latter selects the first descendant para element; the former selects all descendant para elements that are the first para children of their parents.

4. A step consisting of . returns the context item. This is particularly useful in conjunction with //. For example, the path expression .//para returns all para descendant elements of the context node.

5. A step consisting of .. is short for parent::node(). For example, ../title is short for parent::node()/child::title and so will select the title children of the parent of the context node.

Here are some examples of path expressions that use the abbreviated syntax:

• para selects the para element children of the context node

• * selects all element children of the context node

• text() selects all text node children of the context node

• @name selects the name attribute of the context node

• @* selects all the attributes of the context node

• para[1] selects the first para child of the context node

• para[xf:last()] selects the last para child of the context node

• */para selects all para grandchildren of the context node

• /doc/chapter[5]/section[2] selects the second section of the fifth chapter of the doc

• chapter//para selects the para element descendants of the chapter element children of the context node

• //para selects all the para descendants of the document root and thus selects all para elements in the same document as the context node

• //list/member selects all the member elements in the same document as the context node that have an list parent

• . selects the context node

• .//para selects the para element descendants of the context node

• .. selects the parent of the context node

• ../@lang selects the lang attribute of the parent of the context node

• para[@type="warning"] selects all para children of the context node that have a type attribute with value warning

• para[@type="warning"][5] selects the fifth para child of the context node that has a typeattribute with value warning

• para[5][@type="warning"] selects the fifth para child of the context node if that child has a type attribute with value warning

• chapter[title="Introduction"] selects the chapter children of the context node that have one or more title children with string-value equal to Introduction

• chapter[title] selects the chapter children of the context node that have one or more title children

• employee[@secretary and @assistant] selects all the employee children of the context node that have both a secretary attribute and an assistant attribute

• book/(chapter|appendix)/section selects every section element that has a parent that is either a chapter or an appendix element, that in turn is a child of a book element that is a child of the context node.

• book/xf:id(publisher)/name returns the same result as xf:id(book/publisher)/name.

3.3.1 Constructing Sequences