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 variable definitions may also be provided by the environment external to a query. (See Issue 307.)

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

  For each atomic type in the in-scope schema definitions, there is a constructor function in the in-scope functions. Constructor functions are discussed in 3.12.5 Constructor Functions.

• 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 fn:document function when resolving the relative URI of a document to be loaded, if no explicit base URI is supplied in the function call.

XQuery Version 1.0 includes XPath Version 2.0 as a subset. In addition to the static context items listed above, XPath 2.0 requires a static context item named XPath 1.0 compatibility mode. Since XQuery does not support this mode, it always sets this context item to false when evaluating an XPath expression.

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 and the predicate expression E1[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.

• 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 or E1[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 fn:position(). When an expression E1/E2 or E1[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 or E1[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. Variable types and values may also be provided by the environment external to the query. (See Issue 307.)

• 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 fn:current-date, fn:current-time, and fn: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. Informally, document order corresponds to a depth-first, left-to-right traversal of the nodes in the Data Model.

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, and the children of an element node occur before its following siblings. 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 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 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 either to produce a value of type T or to raise a dynamic 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 error is raised.

It is possible for static analysis of an expression to raise a 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 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.

During the analysis phase, it may be desirable for an implementation to issue a warning if the static type assigned to an expression other than () is empty, indicating that the expression can never return a nonempty value. This can catch cases in which a query references an element or attribute that is not present, possibly due to a misspelling or misunderstanding. We suggest a warning rather than requiring an error because there are some situations in which a correct expression may have the type empty.

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

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.6.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 type errors and/or static errors. Type errors reported by the analysis phase occur when the static type of an expression is not correct for the context in which it appears. Static errors are non-type-related errors such as syntax errors. The means by which errors are reported during the analysis phase is implementation-defined.

The result of the evaluation phase is either a result value, a type error, or a dynamic error. Type errors are raised during the evaluation phase when the dynamic type of an expression is not correct for the context in which it appears. Dynamic errors are non-type-related errors such as numeric overflow. If evaluation of an expression yields a value (that is, it does not raise an error), the value must be the value specified by the dynamic semantics defined in [XQuery 1.0 Formal Semantics].

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 in the lexical space of xs:decimal), the implementation is allowed to report this error during the analysis phase (as well as during the evaluation phase).

[XQuery 1.0 Formal Semantics] defines the set of static, dynamic, and type 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.

In addition to the errors defined in this specification, an implementation may specify a list of resource-related limitations, such as maximum numbers or sizes of various objects. These limitations, and the consequences of exceeding them, are implementation-defined.

2.6.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.6.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) + xs:decimal($z)

both ($x div $y) and xs: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 fn:error function, which only raises an error and never returns a value. The fn: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:

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

2.6.4 Errors and Optimization

Because different implementations may choose to evaluate or optimize an expression in different ways, the detection and reporting of dynamic errors is implementation dependent.

When an implementation is able to evaluate an expression without evaluating some subexpression, the implementation is never required to evaluate that subexpression solely to determine whether it raises a dynamic error. For example, if a function parameter is never used in the body of the function, an implementation may choose whether to evaluate the expression bound to that parameter in a function call.

In some cases, an optimizer may be able to achieve substantial performance improvements by rearranging an expression so that the underlying operations such as projection, restriction, and sorting are performed in a different order than that specified in [XQuery 1.0 Formal Semantics]. In such cases, dynamic errors may occur that could not have occurred if the expression were evaluated as written. For example, consider the following expression:

$N[@x castable as xs:date]
      [xs:date(@x) gt xs:date("2000-01-01")]

This expression cannot fail with a casting error if it is evaluated exactly as written. An implementation is permitted, however, to reorder the predicates to achieve better performance (for example, by taking advantage of an index). This reordering could cause the above expression to fail. However, an expression must not be rearranged in a way that causes it to return a non-error result that is different from the result defined by [XQuery 1.0 Formal Semantics].

To avoid unexpected errors caused by reordering of expressions, tests that are designed to prevent dynamic errors should be expressed using conditional expressions, as in the following example:

$N[if (@x castable as xs:date)
   then xs:date(@x) gt xs:date("2000-01-01")
   else false()]

In the case of a conditional expression, the implementation is required not to evaluate the then branch if the condition is false, and not to evaluate the else branch if the condition is true. Conditional and typeswitch expressions are the only kinds of expressions that provide guaranteed conditions under which a particular subexpression will not be evaluated.

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.

A URL Literal is defined equivalently to a string literal.

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 fn:true() and fn: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.

• fn:dayTimeDuration("PT5H") returns an item whose type is fn: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.

In XQuery, the kinds of expressions that can bind variables are FLWOR expressions (3.8 FLWOR Expressions), quantified expressions (3.11 Quantified Expressions), and typeswitch expressions (3.12.2 Typeswitch). Function calls also bind values to the formal parameters of functions before executing the function body. Variables can also be bound in the external environment, outside the scope of a query.

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 is evaluated as follows:

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

2. Each argument value is converted by applying 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.

   When a converted argument value is bound to a function parameter, the argument value retains its most specific type, even though this may be a subtype of the type of the formal parameter. For example, a function with a parameter $p of type xs:decimal can be invoked with an argument of type xs:integer, which is derived from xs:decimal. During the processing of this function invocation, the dynamic type of $p inside the body of the function is considered to be xs:integer.

   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 raises a static error.

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

• If the expected type is a sequence of an atomic type (possibly with an occurrence indicator *, +, or ?), the following conversions are applied:

  1. Atomization is applied to the given value, resulting in a sequence of atomic values.

  2. Each item in the atomic sequence that is of type xs:anySimpleType is cast to the required atomic type.

  3. For each numeric item in the atomic sequence that can be promoted to the expected atomic type using the promotion rules in B.1 Type Promotion, the promotion is done.

• If, after the above conversions, the resulting value does not match the expected type according to the rules for SequenceType Matching, a type error is raised. Note that the rules for SequenceType Matching permit a value of a derived type to be substituted for a value of its base type.

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 anywhere that ignorable whitespace is allowed, 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 be processed as element content.

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

2. Otherwise, the predicate truth value is the Effective Boolean Value of the predicate expression.

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 a list parent and that are in the same document as the context node

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

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

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

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

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

• /child::doc/child::chapter[fn:position() = 5]/child::section[fn: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'][fn:position() = 5]selects the fifth para child of the context node that has a type attribute with value warning

• child::para[fn: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][fn:position() = fn: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[fn: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 a list parent

• . selects the context item

• .//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/fn:id(publisher)/name returns the same result as fn:id(book/publisher)/name.

3.3.1 Constructing Sequences

One way to construct a sequence is by using the comma operator, which evaluates each of its operands and concatenates the resulting values, in order, into a single result sequence.

An ExprSequence is not an expression in its own right, and in general it must be enclosed in parentheses when used in a context where an expression is expected. There are, however, some contexts where parentheses are not required. These include the top-level QueryBody, and the contents of an enclosed expression in an element, attribute, or document constructor (where an ExprSequence appears between curly braces). Empty parentheses can be used to denote an empty sequence.

A sequence may contain duplicate values or nodes, but a sequence is never an item in another sequence. When a new sequence is created by concatenating two or more input sequences, the new sequence contains all the items of the input sequences and its length is the sum of the lengths of the input sequences.

Here are some examples of expressions that construct sequences:

• This expression is a sequence of five integers:

  (10, 1, 2, 3, 4)

• This expression constructs one sequence from the sequences 10, (1, 2), the empty sequence (), and (3, 4):

  (10, (1, 2), (), (3, 4))

  It evaluates to the sequence:

  10, 1, 2, 3, 4

• This expression contains all salary children of the context node followed by all bonus children:

  (salary, bonus)

• Assuming that $price is bound to the value 10.50, this expression:

  ($price, $price)

  evaluates to the sequence

  10.50, 10.50

A RangeExpr can be used to construct a sequence of consecutive integers. The to operator takes two operands, both of which have a required type of integer. A sequence is constructed containing the two integer operands and every integer between the two operands. If the first operand is less than the second, the sequence is in increasing order, otherwise it is in decreasing order.

• This example uses a range expression as one operand in constructing a sequence:

  (10, 1 to 4)

  It evaluates to the sequence:

  10, 1, 2, 3, 4

• This example constructs a sequence of length one:

  10 to 10

  It evaluates to a sequence consisting of the single integer 10.

3.3.2 Combining Sequences

XQuery provides several operators for combining sequences of nodes. The union and | operators are equivalent. They take two node sequences as operands and return a sequence containing all the nodes that occur in either of the operands. The intersect operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in both operands. The except operator takes two node sequences as operands and returns a sequence containing all the nodes that occur in the first operand but not in the second operand. All of these operators return their result sequences in document order without duplicates based on node identity. If an operand of union, intersect, or except contains an item that is not a node, a dynamic error is raised.

Here are some examples of expressions that combine sequences. Assume the existence of three element nodes that we will refer to by symbolic names A, B, and C. Assume that $seq1 is bound to a sequence containing A and B, $seq2 is also bound to a sequence containing A and B, and $seq3 is bound to a sequence containing B and C. Then:

• $seq1 union $seq1 evaluates to a sequence containing A and B.

• $seq2 union $seq3 evaluates to a sequence containing A, B, and C.

• $seq1 intersect $seq1 evaluates to a sequence containing A and B.

• $seq2 intersect $seq3 evaluates to a sequence containing B only.

• $seq1 except $seq2 evaluates to the empty sequence.

• $seq2 except $seq3 evaluates to a sequence containing A only.

In addition to the sequence operators described here,[XQuery 1.0 and XPath 2.0 Functions and Operators] includes functions for indexed access to items or sub-sequences of a sequence, for indexed insertion or removal of items in a sequence, and for removing duplicate values or nodes from a sequence.

3.5.1 Value Comparisons

Value comparisons are intended for comparing single values. The result of a value comparison is defined by applying the following rules, in order:

1. Atomization is applied to each operand. If the result is not an empty sequence or a single atomic value, a type error is raised.

2. If either operand is an empty sequence, the result is an empty sequence.

3. If either operand has the most specific type xs:anySimpleType, that operand is cast to a required type, which is determined as follows:

   • If the type of the other operand is numeric, the required type is xs:double.

   • If the most specific type of the other operand is xs:anySimpleType, the required type is xs:string.

   • Otherwise, the required type is the type of the other operand.

   If the cast fails, a dynamic error is raised.

4. The result of the comparison is true if the value of the first operand is (equal, not equal, less than, less than or equal, greater than, greater than or equal) to the value of the second operand; otherwise the result of the comparison is false. B.2 Operator Mapping describes which combinations of atomic types are comparable, and how comparisons are performed on values of various types. If the value of the first operand is not comparable with the value of the second operand, a type error is raised.

Here are some examples of value comparisons:

• The following comparison is true only if $book1 has a single author subelement and its value is "Kennedy":

  $book1/author eq "Kennedy"

• The following comparison is true because the two constructed nodes have the same value, even though they have different identities:

  <a>5</a> eq <a>5</a>

• The following comparison is true if hatsize and shoesize are both user-defined types that are derived by restriction from a primitive numeric type:

  hatsize(5) eq shoesize(5)

Ed. Note: The current definitions of the value comparison operators are not transitive. For example, anySimpleType('1') lt integer(2) is true and integer(2) lt anySimpleType('03') is true, but anySimpleType('1') lt anySimpleType('03') is false. It is not possible to preserve all of the following properties: (a) age > 21 is compared in the numeric domain when age is untyped; (b) city = county is compared in the string domain when both sides are untyped; (c) value comparisons are transitive; and (d) general comparisons are defined by adding existential quantifiers to value comparisons. The current design gives up property (c). This issue is still under discussion.

3.5.2 General Comparisons

Each of the value comparison operators has a corresponding general comparison operator that is defined by adding existential semantics to the value comparison operator. The operands of a general comparison may be sequences of any length. The result of a general comparison is always true or false.

The correspondence between value comparison and general comparison operators is shown in the following table:

For each value comparison operator VC, the corresponding general comparison operator GC is defined as follows:

A GC B is true for sequences A and B if the value comparison a VC b is true for some item a in A and some item b in B.

• a is numeric, and a VC fn:number(b) is true

• b is numeric, and fn:number(a) VC b is true

Otherwise, A GC B is false.

When evaluating a general comparison in which either operand is a sequence of items, an implementation may return true as soon as it finds an item in the first operand and an item in the second operand for which the underlying value comparison is true. Similarly, a general comparison may raise a dynamic error as soon as it encounters an item in either operand that raises an error. As a result of these rules, the result of a general comparison is not deterministic in the presence of errors.

Here is an example of a general comparison:

• The following comparison is true if the value of any author subelement of $book1 has the string value "Kennedy":

  $book1/author = "Kennedy"

3.5.3 Node Comparisons

The result of a node comparison is defined by applying the following rules, in order:

1. Each operand must be either a single node or an empty sequence; otherwise a type error is raised.

2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

3. A comparison with the is operator is true if the two operands are nodes that have the same identity; otherwise it is false. A comparison with the isnot operator is true if the two operands are nodes that have different identities; otherwise it is false. See [XQuery 1.0 and XPath 2.0 Data Model] for a discussion of node identity.

Use of the is operator is illustrated below.

• The following comparison is true only if the left and right sides each evaluate to exactly the same single node:

  //book[isbn="1558604820"] is //book[call="QA76.9 C3845"]

• The following comparison is false because each constructed node has its own identity:

  <a>5</a> is <a>5</a>

3.5.4 Order Comparisons

The result of an order comparison is defined by applying the following rules, in order:

1. Both operands must be either a single node or an empty sequence; otherwise a type error is raised.

2. If either operand is an empty sequence, the result of the comparison is an empty sequence.

3. A comparison with the << operator returns true if the first operand node is earlier than the second operand node in document order; otherwise it returns false.

4. A comparison with the >> operator returns true if the first operand node is later than the second operand node in document order; otherwise it returns false.

Here is an example of an order comparison:

• The following comparison is true only if the node identified by the left side occurs before the node identified by the right side in document order:

  //purchase[parcel="28-451"] << //sale[parcel="33-870"]

3.7.1 Element Constructors

An element constructor creates an XML element. If the name, attributes, and content of the element are all constants, the element constructor is based on standard XML notation. For example, the following expression creates a book element that contains attributes, subelements, and text:

<book isbn="isbn-0060229357">
    <title>Harold and the Purple Crayon</title>
    <author>
        <first>Crockett</first>
        <last>Johnson</last>
    </author>
</book>

In an element constructor, the name used in an end tag must match the name of the corresponding start tag.

In an element constructor, curly braces { } delimit enclosed expressions, distinguishing them from literal text. Enclosed expressions are evaluated and replaced by their value, whereas material outside curly braces is simply treated as literal text, as illustrated by the following example:

<example>
   <p> Here is a query. </p>
   <eg> $i//title </eg>
   <p> Here is the result of the above query. </p>
   <eg>{ $i//title }</eg>
</example>

The above query might generate the following result (whitespace has been added for readability to this result and other result examples in this document):

<example>
  <p> Here is a query. </p>
  <eg> $i//title </eg>
  <p> Here is the result of the above query. </p>
  <eg><title>Harold and the Purple Crayon</title></eg>
</example>

In general, the value of an enclosed expression may be any sequence of nodes and/or atomic values. Enclosed expressions can be used inside constructors to compute the content of the constructed node (and, in the case of an element constructor, its attributes as well). The details of how enclosed expressions are handled inside various kinds of constructors are given in 3.7.4 Data Model Representation.

Since XQuery uses curly braces to denote enclosed expressions, some convention is needed to denote a curly brace used as an ordinary character. For this purpose, two adjacent curly brace characters occurring within the content of an element or attribute are interpreted by XQuery as a single curly brace character.

The names used in an element constructor may be qualified names that include namespace prefixes. Namespace prefixes can be bound to namespaces in the Query Prolog or in namespace declaration attributes. It is a static error to use a namespace prefix that has not been bound to a namespace.

A namespace declaration attribute serves to define a namespace prefix for use within the scope of an element constructor. A namespace declaration attribute always has the name xmlns or a QName with the prefix xmlns. If the value of a namespace declaration attribute is not a literal string, a static error is raised. Namespace declaration attributes are discussed further in 4.1 Namespace Declarations and [XML Names]. The following element constructor illustrates the use of namespace declaration attributes that define the namespace prefixes metric and english:

<box xmlns:metric = "http://example.org/metric/units"
     xmlns:english = "http://example.org/english/units">
  <height> <metric:meters>3</metric:meters> </height>
  <width> <english:feet>6</english:feet> </width>
  <depth> <english:inches>18</english:inches> </depth>
</box>

3.7.2 Computed Constructors

An alternative way to create nodes is by using a computed constructor. A computed constructor begins with a keyword that identifies the type of node to be created: element, attribute, document, or text. The keyword element or attribute is followed by the name of the node to be created (document and text nodes have no name). The name of an element or attribute may be specified either by a QName or by an expression, enclosed in braces, that returns a QName. The final part of a computed constructor is a sequence of expressions, enclosed in braces, that generates the content of the node.

The sequence of expressions that generates the content of a computed element is called the content sequence. If the content sequence contains an attribute node following an item that is not an attribute node, an error is raised. The attribute nodes generated by the content sequence become attributes of the constructed element. All other items returned by the content sequence, in order, become the content of the constructed element.

The following example illustrates the use of computed element and attribute constructors in a simple case where the names of the constructed nodes are constants. This example generates exactly the same result as the first example in this section:

element book 
{
    attribute isbn { "isbn-0060229357" },
    element title { "Harold and the Purple Crayon" },
    element author 
    {
        element first { "Crockett" },
        element last { "Johnson" }
    }
} 

A computed element constructor might be used to make a modified copy of an existing element. For example, if the variable $e is bound to an element with numeric content, the following constructor might be used to create a new element with the same name as $e and with numeric content equal to twice the value of $e:

element
   {node-name($e)}
   {2 * data($e)}

One important purpose of computed element and attribute constructors is to allow the name of the constructed node to be computed. We will illustrate this feature by an expression that translates the name of an element from one language to another. Suppose that the variable $dict is bound to a sequence of entries in a translation dictionary. Here is an example entry:

<entry word="address">
   <variant lang="German">Adresse</variant>
   <variant lang="Italian">indirizzo</variant>
</entry> 

Suppose further that the variable $e is bound to the following element:

<address>123 Roosevelt Ave. Flushing, NY 11368</address>

Then the following expression generates a new element in which the name of $e has been translated into Italian and the content of $e (including its attributes, if any) has been preserved. The first enclosed expression after the element keyword generates the name of the element, and the second enclosed expression generates the content and attributes:

  element 
    {expanded-QName("", 
       data($dict/entry[word=name($e)]/variant[lang="Italian"]))}
    {$e/node()}

The result of this expression is as follows:

<indirizzo>123 Roosevelt Ave. Flushing, NY 11368</indirizzo>

An attribute generated by a computed element or attribute constructor may not be a namespace declaration attribute--that is, its name may not be xmlns or a QName with prefix xmlns; otherwise, a dynamic error is raised.

Additional examples of computed element constructors can be found in 5.4 Recursive Transformations.

A computed document constructor is useful when the result of a query is to be a document in its own right. The following example illustrates a query that returns an XML document containing a root element is named author-list:

document
   {
      <author-list>
         document("bib.xml")//book/author
      </author-list>
   }

3.7.3 Whitespace in Constructors

As shown in the above examples, element and attribute constructors may contain literal characters interleaved with enclosed expressions and nested elements. In some cases, enclosed expressions and/or nested elements may be separated only by whitespace characters. For example, in the expression below, the end-tag </title> and the start-tag <author> are separated by a newline character and four space characters:

<book isbn="isbn-0060229357">
    <title>Harold and the Purple Crayon</title>
    <author>
        <first>Crockett</first>
        <last>Johnson</last>
    </author>
</book>

We will refer to whitespace characters that occur by themselves in the boundaries between tags and/or enclosed expressions, as in the above example, as boundary whitespace. Boundary whitespace never occurs in a computed constructor, since the content of a computed constructor consists only of a single enclosed expression. The Query Prolog contains a declaration called xmlspace that controls whether boundary whitespace is preserved by constructors. If xmlspace is not declared in the prolog or is declared as xmlspace = strip, boundary whitespace is not considered significant and is not preserved. On the other hand, if xmlspace = preserve is declared in the prolog, boundary whitespace is considered significant and is preserved.

• Example:

  <a>  {"abc"}  </a>

  If xmlspace is not declared or is declared as xmlspace = strip, this example is equivalent to <a>abc</a>. However, if xmlspace = preserve is declared, this example is equivalent to <a>  abc  </a>.

• Example:

  <a> z {"abc"}</a>

  Since the whitespace surrounding the z is not boundary whitespace, it is always preserved. This example is equivalent to <a> z abc  </a>.

For the purpose of the above rule, whitespace characters generated by character references such as   are not considered to be boundary whitespace, and are always preserved.

• Example:

  <a>&#x20;{"abc"}</a>

  This example is equivalent to <a> abc</a>, regardless of the declaration of xmlspace.

It is important to remember that whitespace generated by an enclosed expression is never considered to be boundary whitespace, and is always preserved.

• Example:

  <a>{"  "}</a>

  This example is equivalent to <a>  </a>, regardless of the declaration of xmlspace.

3.7.4 Data Model Representation

Constructors can best be understood by examining how their constructed nodes are represented in the Data Model. The descriptions in this section apply to both the computed and non-computed forms of constructors. An XQuery implementation is free to use any implementation technique that produces the same result as the processing steps described in this section.

3.7.5 Other Constructors and Comments

The syntax for a CDATA section constructor, a processing instruction constructor, or an XML comment constructor is the same as the syntax of the equivalent XML construct.

The following examples illustrate constructors for processing instructions, comments, and CDATA sections.

<?format role="output" ?>

<!-- Tags are ignored in the following section -->

<![CDATA[ 
    <address>123 Roosevelt Ave. Flushing, NY 11368</address>
]]>

Ed. Note: The Data Model cannot currently represent a CDATA section (see Issue 293).

Note that an XML comment actually constructs an XML comment node. An XQuery comment (see 3.1.5 Comments) is simply a comment used in documenting a query, and is not evaluated. Consider the following example.

{-- This is an XQuery comment --}
<!-- This is an XML comment -->

The result of evaluating the above expression is as follows.

<!-- This is an XML comment -->

3.8.1 For and Let Clauses

The purpose of the for and let clauses in a FLWR expression is to produce a tuple stream in which each tuple consists of one or more bound variables.

The simplest example of a for clause contains one variable and an associated expression. It evaluates the expression and iterates over the items in the resulting sequence, binding the variable to each item in turn.

A for clause may also contain multiple variables, each with an associated expression. In this case, the for clause iterates each variable over the items that result from evaluating its expression. The resulting tuple stream contains one tuple for each combination of values in the Cartesian product of the sequences resulting from evaluating the given expressions. The order of the tuples in the tuple stream is determined by the order of the given expressions, as illustrated in the examples below.

A let clause may also contain one or more variables, each with an associated expression. Unlike a for clause, however, a let clause binds each variable to the result of its associated expression, without iteration. The variable bindings generated by let clauses are added to the binding tuples generated by the for clauses. If there are no for clauses, the let clauses generate one tuple containing all the variable bindings.

Although for and let clauses both bind variables, the manner in which variables are bound is quite different, as illustrated by the following examples. The first example uses a let clause:

let $s := (<one/>, <two/>, <three/>)
return <out>{$s}</out>

The variable $s is bound to the result of the expression (<one/>, <two/>, <three/>). Since there are no for clauses, the let clause generates one tuple that contains the binding of $s. The return clause is invoked for this tuple, creating the following output:

<out>
   <one/>
   <two/>
   <three/>
</out>

The next example is a similar query that contains a for clause instead of a let clause:

for $s in (<one/>, <two/>, <three/>)
return <out>{$s}</out>

In this example, the variable $s iterates over the given expression; first it is bound to <one/>, then to <two/>, and finally to <three/>. One tuple is generated for each of these bindings, and the return clause is invoked for each tuple, creating the following output:

<out>
   <one/>
</out>
<out>
   <two/>
</out>
<out>
   <three/>
</out>

The following example illustrates how binding tuples are generated by a for clause that contains multiple variables. Note that the order of the tuple stream is determined primarily by the order of the sequence bound to the leftmost variable, and secondarily by sequences bound to other variables, working from left to right.

for $i in (1, 2), $j in (3, 4)

The tuple stream generated by the above for clause is as follows (the order is significant):

($i = 1, $j = 3)
($i = 1, $j = 4)
($i = 2, $j = 3)
($i = 2, $j = 4)

A FLWR expression may have multiple for clauses and multiple let clauses. The expressions in each of these clauses may refer to variables that were bound in earlier clauses, as illustrated by the following example in which the functions f, g, and h represent arbitrary expressions that refer to the given variables:

for $x in input()
let $y := f($x)
for $z in g($x, $y)
return h($x, $y, $z)

Each variable bound in a for or let clause may have an optional type declaration, which is a type declared using the syntax in 2.4.2 SequenceType. If the type of a value bound to the variable does not match the declared type according to the rules for SequenceType Matching, a type error is raised. For example, the following expression raises a type error because the variable $salary has a type declaration that is not satisfied by the value that is bound to the variable:

let $salary as xs:decimal :=  "cat"
return $salary * 2

Each variable bound in a for clause may have an associated positional variable that is bound at the same time. The name of the positional variable is preceded by the keyword at. The positional variable always has an implied type of xs:integer. As a variable iterates over the items in a sequence, its positional variable iterates over the ordinal numbers of these items, starting with 1. Positional variables are illustrated by the following for clause:

for $car at $i in ("Ford", "Chevy"),
$pet at $j in ("Cat", "Dog")

The tuple stream generated by the above for clause is as follows (the order is significant):

($i = 1, $car = "Ford", $j = 1, $pet = "Cat")
($i = 1, $car = "Ford", $j = 2, $pet = "Dog")
($i = 2, $car = "Chevy", $j = 1, $pet = "Cat")
($i = 2, $car = "Chevy", $j = 2, $pet = "Dog")

3.8.2 Where Clause

The optional where clause serves as a filter for the tuples of variable bindings generated by the for and let clauses. The expression in the where clause, called the where-expression, is evaluated once for each of these tuples. If the effective boolean value of the where-expression is true, the tuple is retained and its variable bindings are used in an execution of the return clause. If the effective boolean value of the where-expression is false, the tuple is discarded. The effective boolean value of an expression is defined in 2.4.3.2 Effective Boolean Value.

The following expression illustrates how a where clause might be applied to a positional variable in order to perform sampling on an input sequence. This expression approximates the average value in a sequence by sampling one value out of each one hundred input values.

avg(for $x at $i in input() 
    where $i mod 100 = 0   
    return $x)

3.8.3 Order By and Return Clauses

The return clause of a FLWOR expression is evaluated once for each tuple in the tuple stream, and the results of these evaluations are concatenated to form the result of the FLWOR expression. If no order by clause is present, the order of the tuple stream is determined by the orderings of the sequences returned by the expressions in the for clauses. If an order by clause is present, it determines the order of the tuple stream. The order of the tuple stream, in turn, determines the order in which the return clause is evaluated using the variable bindings in the respective tuples.

An order by clause contains one or more ordering specifications, called orderspecs, as shown in the grammar above. For each tuple in the tuple stream, the orderspecs are evaluated, using the variable bindings in that tuple. The relative order of two tuples is determined by comparing the values of their orderspecs, working from left to right until a pair of unequal values is encountered. If the values to be compared are strings, the orderspec may indicate the collation to be used (if no collation is specified, the default collation is used.)

The process of evaluating and comparing the orderspecs is based on the following rules:

• Atomization is applied to the result of the expression in each orderspec. If the result of atomization is neither a single atomic value nor an empty sequence, a type error is raised.

• If the value of an orderspec has the type xs:anySimpleType (such as character data in a schemaless document), it is cast to the type xs:string.

• Each orderspec must return values of the same type for all tuples in the tuple stream, and this type must be a (possibly optional) atomic type for which the gt operator is defined--otherwise, a dynamic error is raised.

When two orderspec values are compared to determine their relative position in the ordering sequence, the greater-than relationship is defined as follows:

• When the orderspec specifies empty least, a value W is considered to be greater than a value V if one of the following is true:

  • V is an empty sequence and W is not an empty sequence.

  • V is NaN, and W is neither NaN nor an empty sequence.

  • No collation is specified, and W gt V is true.

  • A specific collation C is specified, and fn:compare(V, W, C) is less than zero.

• When the orderspec specifies empty greatest, a value W is considered to be greater than a value V if one of the following is true:

  • W is an empty sequence and V is not an empty sequence.

  • W is NaN, and V is neither NaN nor an empty sequence.

  • No collation is specified, and W gt V is true.

  • A specific collation C is specified, and fn:compare(V, W, C) is less than zero.

• When the orderspec specifies neither empty least nor empty greatest, it is implementation-defined whether the rules for empty least or empty greatest are used.

If T1 and T2 are two tuples in the tuple stream, and V1 and V2 are the first pair of values encountered when evaluating their orderspecs from left to right for which one value is greater than the other (as defined above), then:

1. If V1 is greater than V2: If the orderspec specifies descending, then T1 precedes T2 in the tuple stream; otherwise, T2 precedes T1 in the tuple stream.

2. If V2 is greater than V1: If the orderspec specifies descending, then T2 precedes T1 in the tuple stream; otherwise, T1 precedes T2 in the tuple stream.

If neither V1 nor V2 is greater than the other for any pair of orderspecs for tuples T1 and T2, then:

1. If stable is specified, the original order of T1 and T2 is preserved in the tuple stream.

2. If stable is not specified, the order of T1 and T2 in the tuple stream is implementation-defined.

An order by clause makes it easy to sort the result of a FLWOR expression, even if the sort key is not included in the result of the expression. For example, the following expression returns employee names in descending order by salary, without returning the actual salaries:

for $e in input() order by $e/salary return $e/name

The order by clause is the only facility provided by XQuery for specifying an order other than document order. Therefore, every query in which an order other than document order is required must contain a FLWOR expression, even though iteration would not otherwise be necessary. For example, a list of books with price less than 100 might be obtained by a simple path expression such as input()//book[price < 100]. But if these books are to be returned in alphabetic order by title, the query must be expressed as follows:

for $b in input()//book[price < 100]
order by $b/title
return $b

The following example illustrates an order by clause that uses several options. It causes a collection of books to be sorted in primary order by title, and in secondary descending order by price. A specific collation is specified for the title ordering, and in the ordering by price, books with no price are specified to occur last (as though they have the least possible price). Whenever two books with the same title and price occur, the keyword stable indicates that their input order is preserved.

for $b in input()//book
stable order by $b/title collation "eng-us",
   $b/price descending empty least
return $b

3.8.4 Example

The following example illustrates how FLWOR expressions can be nested, and how ordering can be specified at multiple levels of an element hierarchy. The example query inverts a document hierarchy to transform a bibliography into an author list. The input bibliography is a list of books in which each book contains a list of authors. The example is based on the following input:

<bib>
  <book>
    <title>TCP/IP Illustrated</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Advanced Unix Programming</title>
    <author>Stevens</author>
    <publisher>Addison-Wesley</publisher>
  </book>
  <book>
    <title>Data on the Web</title>
    <author>Abiteboul</author>
    <author>Buneman</author>
    <author>Suciu</author>
  </book>
</bib>

The following query transforms the input document into a list in which each author's name appears only once, followed by a list of titles of books written by that author. The distinct-values function is used to eliminate duplicates (by value) from a list of author nodes. The author list, and the lists of books published by each author, are returned in alphabetic order using the default collation.

<authlist>
 {
   for $a in distinct-values(input()//author)
   order by $a
   return
     <author>
        <name>
          { $a/text() }
        </name>
        <books>
          {
            for $b in input()//book[author = $a]
            order by $b/title
            return $b/title 
          }
        </books>
     </author>
 }
</authlist>

The result of the above expression is as follows:

<authlist>
   <author>
      <name>Abiteboul</name>
      <books>
         <title>Data on the Web</title>
      </books>
   </author>
   <author>
      <name>Buneman</name>
      <books>
         <title>Data on the Web</title>
      </books>
   </author>
   <author>
      <name>Stevens</name>
      <books>
         <title>TCP/IP Illustrated</title>
         <title>Advanced Unix Programming</title>
      </books>
   </author>
   <author>
      <name>Suciu</name>
      <books>
         <title>Data on the Web</title>
      </books>
   </author>
</authlist>

3.12.1 Instance Of

The boolean operator instance of returns true if the value of its first operand matches the type named in its second operand, according to the rules for SequenceType Matching; otherwise it returns false. For example:

• 5 instance of xs:integer

  This example returns true because the given value is an instance of the given type.

• 5 instance of xs:decimal

  This example returns true because the given value is an integer literal, and xs:integer is derived by restriction from xs:decimal.

• <a>{5}</a> instance of xs:integer

  This example returns false because the given value is not an integer; instead, it is an element whose typed value is an integer.

• <a>{5}</a> instance of element of type xs:integer

  This example returns false because a constructed but unvalidated element always has a type annotation of xs:anyType.

• validate {<a>{5}</a>} instance of element of type xs:integer

  This example returns true if the validation process is successful and the schema definition for element a calls for content of type xs:integer.

• . instance of element

  This example returns true if the context item is an element node.

3.12.2 Typeswitch

The typeswitch expression chooses one of several expressions to evaluate based on the dynamic type of an input value.

In a typeswitch expression, the typeswitch keyword is followed by an expression enclosed in parentheses, called the operand expression. This is the expression whose type is being tested. The remainder of the typeswitch expression consists of one or more case clauses and a default clause.

Each case clause specifies a SequenceType followed by a return expression. The effective case is the first case clause such that the value of the operand expression matches the SequenceType in the case clause, using the rules of SequenceType Matching. The value of the typeswitch expression is the value of the return expression in the effective case. If the value of the operand expression is not a value of any type named in a case clause, the value of the typeswitch expression is the value of the return expression in the default clause.

A case or default clause may optionally specify a variable name. Within the return expression of the case or default clause, this variable name is bound to the value of the operand expression, and its static type is considered to be the SequenceType named in the case or default clause. If the return expression does not depend on the value of the operand expression, the variable may be omitted from the case or default clause.

The following example shows how a typeswitch expression might be used to process an expression in a way that depends on its dynamic type.

typeswitch($customer/billing-address)
   case $a as element of type USAddress return $a/state
   case $a as element of type CanadaAddress return $a/province
   case $a as element of type JapanAddress return $a/prefecture
   default return "unknown"

3.12.3 Cast

Occasionally it is necessary to convert a value to a specific datatype. For this purpose, XQuery provides a cast expression that creates a new value of a specific type based on an existing value. A cast expression takes two operands: an input expression and a target type. The type of the input expression is called the input type. The target type must be a named atomic type, represented by a QName, optionally followed by the occurrence indicator ? if an empty sequence is permitted. The semantics of the cast expression are as follows:

1. Atomization is performed on the input expression.

2. If the result of atomization is a sequence of more than one atomic value, a type error is raised.

3. If the result of atomization is an empty sequence:

   1. If ? is specified after the target type, the result of the cast expression is an empty sequence.

   2. If ? is not specified after the target type, a type error is raised.

4. If the result of atomization is a single atomic value, the result of the cast expression depends on the input type and the target type. In general, the cast expression attempts to create a new value of the target type based on the input value. Only certain combinations of input type and target type are supported. The rules are listed below. For the purpose of these rules, we use the terms subtype and supertype in the following sense: if type B is derived from type A by restriction, then B is a subtype of A, and A is a supertype of B.

   1. cast is supported for the combinations of input type and target type listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. For each of these combinations, both the input type and the target type are built-in schema types. For example, a value of type xs:string can be cast into the type xs:decimal. For each of these built-in combinations, the semantics of casting are specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].

   2. cast is supported if the input type is a derived atomic type and the target type is a supertype of the input type. In this case, the input value is mapped unchanged into the value space of the target type. For example, if shoesize is derived by restriction from xs:integer, a value of type shoesize can be cast into the type xs:integer.

   3. cast is supported if the target type is a derived atomic type and the input type is xs:string, xs:anySimpleType, or a supertype of the target type. If the input type is xs:string or xs:anySimpleType, its string value must be in the lexical space of the target type, and it is converted to the target type using the schema-defined rules for the target type. If the input type is a supertype of the target type, its value is mapped unchanged into the value space of the target type, and it is checked for conformance to all the facets of the target type (checking of a "pattern" facet may require generating a canonical lexical representation of the input value.)

   4. If a primitive type P1 can be cast into a primitive type P2, then any subtype of P1 can be cast into any subtype of P2, provided that the facets of the target type are satisfied. First the input value is cast to P1 using rule (b) above. Next, the value of type P1 is cast to the type P2, using rule (a) above. Finally, the value of type P2 is cast to the target type, using rule (c) above.

   5. For any combination of input type and target type that is not in the above list, a cast expression raises a static error.

If casting from the input type to the target type is supported but nevertheless it is not possible to cast the input value into the value space of the target type, a dynamic error is raised. This includes the case when any facet of the target type is not satisfied. For example, cast as xs:integer($x) raises a dynamic error if the type of $x is xs:decimal and its value is 4.99 because this value cannot be represented with zero fractional digits.

3.12.4 Castable

XQuery provides a form of a predicate that tests whether a given value is castable into a given target type. The expression V castable as T returns true if the value V can be successfully cast into the target type T; otherwise it returns false. The castable predicate can be used to avoid errors at evaluation time. It can also be used to select an appropriate type for processing of a given value, as illustrated in the following example:

if ($x castable as hatsize)
then cast as hatsize($x)
else if ($x castable as IQ)
then cast as IQ($x)
else cast as string($x)

3.12.5 Constructor Functions

Constructor functions provide an alternative syntax for casting.

For every built-in type T that is defined in [XML Schema], as well as the duration subtypes fn:dayTimeDuration and fn:yearMonthDuration, a built-in constructor function is provided. The signature of the built-in constructor function for type T is as follows:

T($x as item) as T

The constructor function for type T accepts any single item (either a node or an atomic value) as input, and returns a value of type T (or raises a dynamic error). Its semantics are exactly the same as a cast expression with target type T. The built-in constructor functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators]. The following are examples of built-in constructor functions:

• This example is equivalent to cast as xs:date("2000-01-01").

  xs:date("2000-01-01")

• This example is equivalent to cast as xs:decimal($floatvalue * 0.2E-5).

  xs:decimal($floatvalue * 0.2E-5)

• This example returns a dayTimeDuration value equal to 21 days. It is equivalent to cast as fn:dayTimeDuration("P21D").

  fn:dayTimeDuration("P21D")

For each user-defined atomic type T in the in-scope schema definitions, a constructor function is effectively defined. Like the built-in constructor functions, the constructor functions for user-defined types have the same name as the type, accept any item as input, and have semantics identical to a cast expression with the user-defined type as target type. For example, if usa:zipcode is a user-defined atomic type in the in-scope schema definitions, then the expression usa:zipcode("12345") is equivalent to the expression cast as usa:zipcode("12345").

If the argument to any constructor function is a literal value, the result of the function may be computed statically, and an error encountered in this process may be reported as a static error.

3.12.6 Treat

XQuery provides an expression called treat that can be used to modify the static type of its operand.

Like cast, the treat expression takes two operands: an expression and a SequenceType. Unlike cast, however, treat does not change the dynamic type or value of its operand. Instead, the purpose of treat is to ensure that an expression has an expected type at evaluation time.

The semantics of treat as type1 (expr2) are as follows:

• During static analysis (if the Static Typing Feature is implemented):

  type1 must be a subtype of the static type of expr2, using the definition of subtype in [XQuery 1.0 Formal Semantics]--otherwise, a type error is raised. The static type of the treat expression is type1. This enables the expression to be used as an argument of a function that requires a parameter of type1.

• During expression evaluation (at "run-time"):

  If expr2 matches type1, using the SequenceType Matching rules in 2.4.2 SequenceType, the treat expression returns the value of expr2; otherwise, it raises a dynamic error. If the value of expr2 is returned, its identity is preserved. The treat expression ensures that the value of its expression operand conforms to the expected type at run-time.

• Example:

  treat as element of type USAddress ($myaddress)

  The static type of $myaddress may be element of type Address, a less specific type than element of type USAddress. However, at run-time, the value of $myaddress must match the type element of type USAddress using SequenceType Matching rules; otherwise a dynamic error is raised.