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

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, resulting in a single atomic value or an empty sequence for each operand.

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

3. If either operand has the 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 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. If the value comparison has two numeric operands of different types, one of the operands is promoted to the type of the other operand, following the promotion rules in B.1 Type Promotion. For example, a value of type xs:integer can be promoted to xs:decimal, and a value of type xs:decimal can be promoted to xs:double.

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

Ed. Note: The current definitions of the value comparison operators are not transitive. The Working Group is discussing making value comparisons transitive by removing some implicit casts from value comparisons and adding them to general comparisons.

3.5.2 General Comparisons

General comparisons are defined by adding existential semantics to value comparisons. The operands of a general comparison may be sequences of any length. The result of a general comparison is always true or false.

The general comparison A = B is true for sequences A and B if the value comparison a eq b is true for some item a in A and some item b in B. Otherwise, A = B is false.

Similarly:

• A != B is true if and only if a ne b is true for some a in A and some b in B.

• A < B is true if and only if a lt b is true for some a in A and some b in B.

• A <= B is true if and only if a le b is true for some a in A and some b in B.

• A > B is true if and only if a gt b is true for some a in A and some b in B.

• A >= B is true if and only if a ge b is true for some a in A and some b in B.

Here is an example of a general comparison:

• The following comparison is true if the value of any author subelement of $book1 is "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 dynamic 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 dynamic 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 an element constructor, an enclosed expression may evaluate to any sequence of nodes and/or atomic values. Attribute nodes occurring in this sequence become the attributes of the constructed element. The remainder of the sequence becomes the content of the constructed element.

An enclosed expression may also be used to compute the value of an attribute. If the enclosed expression returns a node, the typed value of the node is extracted and assigned to the attribute, as illustrated by the following example:

<book isbn="{$i/@booknum}" />

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, or document. The keyword element or attribute is followed by the name of the node to be created (document nodes have no name). The name of an element or attribute may be specified either by a QName or by an enclosed expression that returns a QName. The final part of a computed constructor is an enclosed expression that generates the content of the node.

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 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
   {xf:node-name($e)}
   {2 * xf: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 
    {xf:expanded-QName("", 
       xf: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. In order to conform to the rules of [XML], the constructed document should contain exactly one top-level element node which serves as the root of the document (of course, this root element may in turn contain subelements.) The following example illustrates a query that returns an XML document whose 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. The Query Prolog contains a declaration called xmlspace that controls whether boundary whitespace is preserved by element and attribute 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

Element and attribute constructors can best be understood by examining how their values are represented in the Data Model. The descriptions in this section apply to both the computed and non-computed forms of element and attribute 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.9.1 Sort Expressions

The value of the expression on the left side of the sort by keyword is called the input sequence. The items in the input sequence are called input items. The result of the sorting expression is called the output sequence. The output sequence contains all the input items, retaining their original identities (if any), but possibly in a different order.

The expressions on the right side of the sort by keyword are called ordering expressions. For each input item, the ordering expressions are evaluated with an inner focus derived from the input item, as described in 2.1.2 Evaluation Context. The input items are then reordered according to the values of their respective ordering expressions. If more than one ordering expression is specified, the leftmost ordering expression controls the primary sort, followed by the remaining ordering expressions from left to right. Each ordering expression can be followed by the keyword ascending or descending, which specifies the direction of the sort (ascending is the default). An ordering expression can also be followed by the optional keywords empty greatest or empty least, which specify the placement of input items whose ordering expression returns the empty sequence.

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

1. Atomization is applied to the result of each ordering expression, resulting in a single atomic value or an empty sequence for each operand ordering expression.

2. If the result of an ordering expression has the type xs:anySimpleType (such as character data in a schemaless document), it is cast to the type xs:string.

3. Each ordering expression must return values of the same type for all input items, and this type must be a (possibly optional) atomic type for which the gt operator is defined--otherwise, a dynamic error is raised.

4. For the purpose of the following rule:

   1. For any ordering expression in which empty greatest is specified, an ordering value that is an empty sequence is treated as greater than any non-empty ordering value (that is ( ) gt x is true for any non-empty x.)

   2. For any ordering expression in which empty least is specified, an ordering value that is an empty sequence is treated as less than any non-empty ordering value (that is x gt ( ) is true for any non-empty x.)

   3. For any ordering expression in which neither empty greatest nor empty least is specified, an implementation may consistently treat an ordering value that is an empty sequence either as greater than any non-empty ordering value or as less than any non-empty ordering value.

5. If V1 and V2 are the values of an ordering expression for input items I1 and I2 respectively, then:

   1. If the ordering expression is ascending, and if V2 gt V1 is true, then I1 precedes I2 in the output sequence.

   2. If the ordering expression is descending, and if V1 gt V2 is true, then I1 precedes I2 in the output sequence.

   3. If neither V1 gt V2 nor V2 gt V1 is true, and stable is specified, then the input order of I1 and I2 is preserved in output sequence.

   4. If neither V1 gt V2 nor V2 gt V1 is true, and stable is not specified, then the order of I1 and I2 in the output sequence is implementation-defined.

Here are some examples of ordering expressions:

• This example lists all books with price greater than 100, in order by first author; within each group of books with the same first author, the books are ordered by title.

  //book[price > 100] sort by (author[1], title)

• This example shows how the "." notation can be used to sort a sequence of atomic values (in this case, strings). The example returns all the authors of a given set of books, in alphabetic order.

  data(//book/author) sort by (.)

• Ordering may be specified at multiple levels of a query result. The following example returns an alphabetic list of publishers. Within each publisher element it returns a list of books, each containing a title and a price, in descending order by price.

  <publisher_list>
     {for $p in distinct-values(document("bib.xml")//publisher)
      return
         <publisher>
            <name> {$p/text()} </name> 
            {for $b in document("bib.xml")//book[publisher = $p]
             return
                <book>
                   {$b/title}
                   {$b/price}
                </book> 
             sort by(price descending)
            }
         </publisher> 
      sort by(name)
     }
  </publisher_list>

(employees sort by (salary))/name

for $e in (employees sort by (salary)) return $e/name

3.9.2 Unordered Expressions

The unordered keyword may be used as a prefix to any expression to indicate that its order is not significant. This feature allows an implementation to enhance performance by materializing a sequence of values in the most efficient way it can find.

The use of unordered is illustrated by the following example, which joins together two documents named parts.xml and suppliers.xml. The example returns the part numbers of red parts, paired with the supplier numbers of suppliers who supply these parts. If unordered were not specified, the resulting list of (part number, supplier number) pairs would be required to have an ordering that is controlled primarily by the document order of parts.xml and secondarily by the document order of suppliers.xml. However, this might not be the most efficient way to process the query if the ordering of the result is not important. An XQuery implementation might be able to process the query more efficiently by using an index to find the red parts, or by using suppliers.xml rather than parts.xml to control the primary ordering of the result. The unordered keyword gives the query evaluator freedom to make these kinds of optimizations.

unordered
for $p in document("parts.xml")//part[color = "Red"],
    $s in document("suppliers.xml")//supplier
where $p/suppno = $s/suppno
return
    <ps>
       { $p/partno, $s/suppno }
    </ps>

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.

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

• 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 an optional variable and 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.

During evaluation of the return expression in a case or default clause, the variable named in the clause is bound to the value of the operand expression. 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 element of type USAddress $a return $a/state
   case element of type CanadaAddress $a return $a/province
   case element of type JapanAddress $a return $a/prefecture
   default return "unknown"

3.12.3 Cast and Treat

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 SequenceType, called the target type. The cast expression first performs atomization on its input expression, resulting in a single atomic input value or the empty sequence. If the input value is the empty sequence, the cast expression returns an empty sequence. Otherwise, the cast expression creates a new instance of the target type that has the same lexical representation as the input value. The type of the input value is called the input type. cast is supported only for certain combinations of input type and target type, as 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.

• 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 every built-in type T that is defined in [XML Schema], a constructor function is provided whose name is the same as T and whose semantics are the same as a cast expression with target type T. For example, the function call xs:decimal($stringvalue) is equivalent to the expression cast as xs:decimal($stringvalue). If the argument to a constructor function is a literal, the result of the function may be computed statically, and an error encountered in this process may be reported as a static error. Constructor functions are described in more detail in [XQuery 1.0 and XPath 2.0 Functions and Operators].

• cast is supported if the input type is a derived atomic type and the target type is a supertype of the input 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.

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

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

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

In addition to cast, XQuery provides a type-checking expression called treat, which takes two operands: an expression and a SequenceType. Unlike cast, however, treat does not change the type or value of its operand. Instead, the purpose of treat is to ensure that an expression has an expected type at run-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 static 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.