XQuery 4.0: An XML Query Language

4 Expressions

This section discusses each of the basic kinds of expression. Each kind of expression has a name such as PathExpr, which is introduced on the left side of the grammar production that defines the expression. Since XQuery 4.0 is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.

The order in which expressions are discussed in this document does not reflect the order of operator precedence. In general, this document introduces the simplest kinds of expressions first, followed by more complex expressions. For the complete grammar, see Appendix [A XQuery 4.0 Grammar].

[Definition: A query consists of one or more modules.] If a query is executable, one of its modules has a Query Body containing an expression whose value is the result of the query. An expression is represented in the XQuery grammar by the symbol Expr.

`Expr`	::=	`(ExprSingle ++ ",")`
`ExprSingle`	::=	`FLWORExpr \| QuantifiedExpr \| SwitchExpr \| TypeswitchExpr \| IfExpr \| TryCatchExpr \| OrExpr`

`ExprSingle`	::=	`FLWORExpr \| QuantifiedExpr \| SwitchExpr \| TypeswitchExpr \| IfExpr \| TryCatchExpr \| OrExpr`
`FLWORExpr`	::=	`InitialClauseIntermediateClause* ReturnClause`
`QuantifiedExpr`	::=	`("some" \| "every") (QuantifierBinding ++ ",") "satisfies" ExprSingle`
`SwitchExpr`	::=	`"switch" SwitchComparand (SwitchCases \| BracedSwitchCases)`
`TypeswitchExpr`	::=	`"typeswitch" "(" Expr ")" (TypeswitchCases \| BracedTypeswitchCases)`
`IfExpr`	::=	`"if" "(" Expr ")" (UnbracedActions \| BracedAction)`
`TryCatchExpr`	::=	`TryClause ((CatchClause+ FinallyClause?) \| FinallyClause)`
`OrExpr`	::=	`AndExpr ("or" AndExpr)*`

The XQuery 4.0 operator that has lowest precedence is the comma operator, which is used to combine two operands to form a sequence. As shown in the grammar, a general expression (Expr) can consist of multiple ExprSingle operands, separated by commas.

The name ExprSingle denotes an expression that does not contain a top-level comma operator (despite its name, an ExprSingle may evaluate to a sequence containing more than one item.)

The symbol ExprSingle is used in various places in the grammar where an expression is not allowed to contain a top-level comma. For example, each of the arguments of a function call must be a ExprSingle, because commas are used to separate the arguments of a function call.

After the comma, the expressions that have next lowest precedence are FLWORExpr,QuantifiedExpr, SwitchExpr, TypeswitchExpr, IfExpr, TryCatchExpr, and OrExpr. Each of these expressions is described in a separate section of this document.

4.13 FLWOR Expressions

XQuery provides a versatile expression called a FLWOR expression that may contain multiple clauses. The FLWOR expression can be used for many purposes, including iterating over sequences, joining multiple documents, and performing grouping and aggregation. The name FLWOR, pronounced "flower", is suggested by the keywords for, let, where, order by, and return, which introduce some of the clauses used in FLWOR expressions (but this is not a complete list of such clauses.)

The overall syntax of a FLWOR expression is shown here, and relevant parts of the syntax are expanded in subsequent sections.

`FLWORExpr`	::=	`InitialClauseIntermediateClause* ReturnClause`
`InitialClause`	::=	`ForClause \| LetClause \| WindowClause`
`ForClause`	::=	`"for" (ForBinding ++ ",")`
`LetClause`	::=	`"let" (LetBinding ++ ",")`
`WindowClause`	::=	`"for" (TumblingWindowClause \| SlidingWindowClause)`
`IntermediateClause`	::=	`InitialClause \| WhereClause \| WhileClause \| GroupByClause \| OrderByClause \| CountClause`
`WhereClause`	::=	`"where" ExprSingle`
`WhileClause`	::=	`"while" ExprSingle`
`GroupByClause`	::=	`"group" "by" (GroupingSpec ++ ",")`
`OrderByClause`	::=	`"stable"? "order" "by" (OrderSpec ++ ",")`
`CountClause`	::=	`"count" VarName`
`ReturnClause`	::=	`"return" ExprSingle`

The semantics of FLWOR expressions are based on a concept called a tuple stream. [Definition: A tuple stream is an ordered sequence of zero or more tuples.] [Definition: A tuple is a set of zero or more named variables, each of which is bound to a value that is an XDM instance.] Each tuple stream is homogeneous in the sense that all its tuples contain variables with the same names and the same static types. The following example illustrates a tuple stream consisting of four tuples, each containing three variables named $x, $y, and $z:

($x = 1003, $y = "Fred", $z = <age>21</age>)
($x = 1017, $y = "Mary", $z = <age>35</age>)
($x = 1020, $y = "Bill", $z = <age>18</age>)
($x = 1024, $y = "John", $z = <age>29</age>)

Note:

In this section, tuple streams are represented as shown in the above example. Each tuple is on a separate line and is enclosed in parentheses, and the variable bindings inside each tuple are separated by commas. This notation does not represent XQuery syntax, but is simply a representation of a tuple stream for the purpose of defining the semantics of FLWOR expressions.

Tuples and tuple streams are not part of the data model. They exist only as conceptual intermediate results during the processing of a FLWOR expression.

Conceptually, the first clause generates a tuple stream. Each clause between the first clause and the return clause takes the tuple stream generated by the previous clause as input and generates a (possibly different) tuple stream as output. The return clause takes a tuple stream as input and, for each tuple in this tuple stream, generates an XDM instance; the final result of the FLWOR expression is the ordered concatenation of these XDM instances.

The initial clause in a FLWOR expression may be a for, let, or window clause. Intermediate clauses may be for, let, window, count, where, group by, or order by clauses. These intermediate clauses may be repeated as many times as desired, in any order. The final clause of the FLWOR expression must be a return clause. The semantics of the various clauses are described in the following sections.

4.13.3 Let Clause

Changes in 4.0 ⬇ ⬆

The value bound to a variable in a let clause is now converted to the declared type by applying the coercion rules. [Issue 189 PR 254 29 November 2022]
Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables. [Issue 37 PR 1942 2055 17 June 2025]

`LetClause`	::=	`"let" (LetBinding ++ ",")`
`LetBinding`	::=	`LetValueBinding \| LetSequenceBinding \| LetArrayBinding \| LetMapBinding`
`LetValueBinding`	::=	`VarNameAndType ":=" ExprSingle`
`VarNameAndType`	::=	`"$" EQNameTypeDeclaration?`
`EQName`	::=	`QName \| URIQualifiedName`
`TypeDeclaration`	::=	`"as" SequenceType`
`SequenceType`	::=	`("empty-sequence" "(" ")") \| (ItemTypeOccurrenceIndicator?)`
`ExprSingle`	::=	`FLWORExpr \| QuantifiedExpr \| SwitchExpr \| TypeswitchExpr \| IfExpr \| TryCatchExpr \| OrExpr`
`LetSequenceBinding`	::=	`"$" "(" (VarNameAndType ++ ",") ")" TypeDeclaration? ":=" ExprSingle`
`LetArrayBinding`	::=	`"$" "[" (VarNameAndType ++ ",") "]" TypeDeclaration? ":=" ExprSingle`
`LetMapBinding`	::=	`"$" "{" (VarNameAndType ++ ",") "}" TypeDeclaration? ":=" ExprSingle`

The purpose of a let clause is to bind values to one or more variables. Each variable is bound to the result of evaluating an expression.

If a let clause declares multiple variables separated by commas, it is semantically equivalent to multiple let clauses, each containing a single variable. For example, the clause

let $x := $expr1, $y := $expr2

is semantically equivalent to the following sequence of clauses:

let $x := $expr1
let $y := $expr2

After performing this expansion, the effect of a let clause is as follows:

If the let expression uses multiple variables, it is first expanded to a set of nested let expressions, each of which uses only one variable. Specifically, any separating comma is replaced by let.
Example:
The expression:
```
let $x := 4, $y := 3 return $x + $y
```
is expanded to:
```
let $x := 4 let $y := 3 return $x + $y
```
In a LetValueBinding such as let $V as T := EXPR:
1. The variable V is declared as a range variable.
2. The sequence type T is called the declared type. If there is no declared type, then item()* is assumed.
3. The expression EXPR is evaluated, and its value is converted to the declared type by applying the coercion rules. The resulting value forms the binding sequence for the range variable.
In a LetSequenceBinding such as let $( $A₁ as T₁, $A₂ as T₂, ... , $A_n as T_n ) as ST := EXPR:
1. The sequence type ST is called the declared sequence type. If there is no declared sequence type, then item()* is assumed.
2. The expression EXPR is evaluated, and its value is converted to the declared sequence type ST by applying the coercion rules. Call the resulting (coerced) value V.
3. Each variable A_i (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let A_i as T_i := items-at(V, i). That is, a range variable named A_i is declared, whose binding sequence is the item V[ i ], after coercion to the type T_i if specified. If T_i is absent, no further coercion takes place (the default is effectively item()?).
  Note:
  If i exceeds the length of the sequence V, then A_i is bound to an empty sequence. This will cause a type error if type T_i does not permit an empty sequence.
  Note:
  It is permissible to bind several variables with the same name; all but the last are shadowedoccluded. A useful convention is therefore to bind items in the sequence that are of no interest to the variable $_: for example let $( $_, $_, $x ) := EXPR effectively binds $x to the third item in the sequence and causes the first two items to be ignored.
  Example:
  The expression:
```
let $( $a, $b as xs:integer, $local:c ) := (2, 4, 6)
return $a + $b + $local:c
```
  is expanded to:
```
let $temp := (2, 4, 6)
let $a := fn:items-at($temp, 1)
let $b as xs:integer := fn:items-at($temp, 2)
let $local:c := fn:items-at($temp, 3)
return $a + $b + $local:c
```
  where $temp is some variable name that is otherwise unused.
  Example:
  Consider the element $E := <e A="p q r" B="x y z"/>, where $E has been validated against a schema that defines both attributes A and B as being lists of strings.
  Then the expression:
```
let $( $a as xs:string*, $b as xs:string* ) := $E/(@A, @B)
```
  binds $a to the sequence ("p", "q", "r") and $b to the sequence ("x", "y", "z"). The evaluation of the expression $E/(@A, @B) returns a sequence of two attribute nodes; the value of $a is formed by atomizing the first of these nodes, while $b is formed by atomizing the second.
In a LetArrayBinding such as let $[ $A₁ as T₁, $A₂ as T₂, ... , $A_n as T_n ] as AT := EXPR:
1. The sequence type AT is called the declared array type. If there is no declared array type, then array(*) is assumed.
2. The expression EXPR is evaluated, and its value is converted to the declared array type AT by applying the coercion rules. A type error [err:XPTY0004] is raised if the result is not a singleton array. Call the resulting (coerced) value V.
3. Each variable A_i (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let A_i as T_i := array:get(V, i, ()). That is, a range variable named A_i is declared, whose binding sequence is the array member V ? i, after coercion to the type T_i if specified. If T_i is absent, no further coercion takes place (the default is effectively item()*).
  Note:
  If i exceeds the length of the array V, then A_i is bound to an empty sequence. This will cause a type error if type T_i does not permit an empty sequence.
  Note:
  It is permissible to bind several variables with the same name; all but the last are shadowedoccluded. A useful convention is therefore to bind items in the sequence that are of no interest to the variable $_: for example let $( $_, $_, $x ) := EXPR effectively binds $x to the third item in the sequence and causes the first two items to be ignored.
  Example:
  The expression:
```
let $[ $a, $b as xs:integer, $local:c ] := [ 2, 4, 6 ]
return $a + $b + $local:c
```
  is expanded to:
```
let $temp := [ 2, 4, 6 ]
let $a := array:get($temp, 1, ())
let $b as xs:integer := array:get($temp, 2, ())
let $local:c := array:get($temp, 3, ())
return $a + $b + $local:c
```
  where $temp is some variable name that is otherwise unused.
In a LetMapBinding such as let ${ $A₁ as T₁, $A₂ as T₂, ... , $A_n as T_n } as MT := EXPR:
1. The sequence type MT is called the declared map type. If there is no declared map type, then map(*) is assumed.
2. The expression EXPR is evaluated, and its value is converted to the declared map type MT by applying the coercion rules. A type error [err:XPTY0004] is raised if the result is not a singleton map. Call the resulting (coerced) value V.
3. Each variable A_i (for i in 1 to n) is effectively replaced by a LetValueBinding of the form let A_i as T_i := map:get(V, "N_i", ()), where N_i is the local part of the name of the variable A_i. That is, a range variable named A_i is declared, whose binding sequence is the value of the map entry in V whose key is an xs:string (or xs:anyURI or xs:untypedAtomic) equal to the local part of the variable name, after coercion to the type T_i if specified. If T_i is absent, no further coercion takes place (the default is effectively item()*).
  Note:
  If there is no entry in the map with a key corresponding to the variable name, then the variable A_i is bound to an empty sequence. This will cause a type error if type T_i does not permit an empty sequence.
  Note:
  It is not possible to use this mechanism to bind variables to values in a map unless the keys in the map are strings in the form of NCNames.
  Example:
  The expression:
```
let ${ $a, $b as xs:integer, $local:c } := { "a": 2, "b": 4, "c": 6, "d": 8 }
return $a + $b + $local:c
```
  is expanded to:
```
let $temp := { "a": 2, "b": 4, "c": 6 }
let $a := map:get($temp, "a", ())
let $b as xs:integer := map:get($temp, "b", ())
let $local:c := map:get($temp, "c", ())
return $a + $b + $local:c
```
  where $temp is some variable name that is otherwise unused.
The effect of the LetClause is to add one or more variable bindings to the tuple stream. Specifically, each range variable declared within the LetClause is bound to its corresponding binding sequence, and the resulting variable binding is added to the current tuple, replacing any existing variable binding with the same variable name.
If the LetClause is the initial clause in a FLWOR expression, it creates an initial tuple for the tuple stream, containing these variable bindings. This tuple stream serves as input to the next clause in the FLWOR expression.
If the LetClause is an intermediate clause in a FLWOR expression, it adds the relevant variable bindings to each tuple in the input tuple stream. The resulting tuples become the output tuple stream of the let clause.
The number of tuples in the output tuple stream of an intermediate let clause is the same as the number of tuples in the input tuple stream. The number of variable bindings in the output tuples is always greater than the number of variable bindings in the input tuples, unless the input tuples already contain bindings for every variable binding created by the LetClause; in this case, the new binding for any given variable name occludes (replaces) an earlier binding for that variable name, and the number of bindings is unchanged.

The semantics of type declarations are further defined in 4.13.1 Variable Bindings.

The following code fragment illustrates how a for clause and a let clause can be used together. The for clause produces an initial tuple stream containing a binding for variable $d to each department number found in a given input document. The let clause adds an additional binding to each tuple, binding variable $e to a sequence of employees whose department number matches the value of $d in that tuple.

for $d in doc("depts.xml")/depts/deptno
let $e := doc("emps.xml")/emps/emp[deptno eq $d]

J Change Log (Non-Normative)

Use the arrows to browse significant changes since the 3.1 version of this specification.
See 1 Introduction
Sections with significant changes are marked Δ in the table of contents.
See 1 Introduction
Setting the default namespace for elements and types to the special value ##any causes an unprefixed element name to act as a wildcard, matching by local name regardless of namespace.
See 3.2.7.2 Element Types
The terms FunctionType, ArrayType, MapType, and RecordType replace FunctionTest, ArrayTest, MapTest, and RecordTest, with no change in meaning.
See 3.2.8.1 Function Types
Record types are added as a new kind of ItemType, constraining the value space of maps.
See 3.2.8.3 Record Types
Function coercion now allows a function with arity N to be supplied where a function of arity greater than N is expected. For example this allows the function true#0 to be supplied where a predicate function is required.
See 3.4.3 Function Coercion
PR 1817 1853
An inline function may be annotated as a %method, giving it access to its containing map.
See 4.5.6 Inline Function Expressions
See 4.5.6.1 Methods
See 4.14.3 Lookup Expressions
The symbols × and ÷ can be used for multiplication and division.
See 4.8 Arithmetic Expressions
The rules for value comparisons when comparing values of different types (for example, decimal and double) have changed to be transitive. A decimal value is no longer converted to double, instead the double is converted to a decimal without loss of precision. This may affect compatibility in edge cases involving comparison of values that are numerically very close.
See 4.10.1 Value Comparisons
Operators such as < and > can use the full-width forms ＜ and ＞ to avoid the need for XML escaping.
See 4.10.2 General Comparisons
PR 1480 1989
When the element name matches a language keyword such as div or value, it must now be written as a QName literal. This is a backwards incompatible change.
See 4.12.3.1 Computed Element Constructors
When the attribute name matches a language keyword such as by or of, it must now be written as a QName literal. This is a backwards incompatible change.
See 4.12.3.2 Computed Attribute Constructors
PR 1513 2028
When the processing instruction name matches a language keyword such as try or validate, it must now be written with a preceding # character. This is a backwards incompatible change.
See 4.12.3.5 Computed Processing Instruction Constructors
When the namespace prefix matches a language keyword such as as or at, it must now be written with a preceding # character. This is a backwards incompatible change.
See 4.12.3.7 Computed Namespace Constructors
The lookup operator ? can now be followed by a string literal, for cases where map keys are strings other than NCNames. It can also be followed by a variable reference.
See 4.14.3 Lookup Expressions
PR 1864 1877
The key specifier can reference an item type or sequence type, to select values of that type only. This is especially useful when processing trees of maps and arrays, as encountered when processing JSON input.
See 4.14.3 Lookup Expressions
PR 1763 1830
The syntax on the right-hand side of an arrow operator has been relaxed; a dynamic function call no longer needs to start with a variable reference or a parenthesized expression, it can also be (for example) an inline function expression or a map or array constructor.
See 4.24 Arrow Expressions
The arrow operator => is now complemented by a “mapping arrow” operator =!> which applies the supplied function to each item in the input sequence independently.
See 4.24.2 Mapping Arrow Expressions
All implementations must now predeclare the namespace prefixes math, map, array, and err. In XQuery 3.1 it was permitted but not required to predeclare these namespaces.
See 5.13 Namespace Declaration
Function definitions in the static context may now have optional parameters, provided this does not cause ambiguity across multiple function definitions with the same name. Optional parameters are given a default value, which can be any expression, including one that depends on the context of the caller (so an argument can default to the context value).
See 5.18 Function Declarations
PR 1023 1128
It has been clarified that function coercion applies even when the supplied function item matches the required function type. This is to ensure that arguments supplied when calling the function are checked against the signature of the required function type, which might be stricter than the signature of the supplied function item.
See 3.4.3 Function Coercion
A dynamic function call can now be applied to a sequence of functions, and in particular to an empty sequence. This makes it easier to chain a sequence of calls.
See 4.5.3.1 Evaluating Dynamic Function Calls
Parts of the static context that were there purely to assist in static typing, such as the statically known documents, were no longer referenced and have therefore been dropped.
See B.1 Static Context Components
The syntax document-node(N), where N is a NameTestUnion, is introduced as an abbreviation for document-node(element(N)). For example, document-node(*) matches any well-formed XML document (as distinct from a document fragment).
See 3.2.7 Node Types
QName literals are new in 4.0.
See 4.2.1.3 QName Literals
PR 159
Keyword arguments are allowed on static function calls, as well as positional arguments.
See 4.5.1.1 Static Function Call Syntax
PR 202
The presentation of the rules for the subtype relationship between sequence types and item types has been substantially rewritten to improve clarity; no change to the semantics is intended.
See 3.3 Subtype Relationships
PR 230
The rules for “errors and optimization” have been tightened up to disallow many cases of optimizations that alter error behavior. In particular there are restrictions on reordering the operands of and and or, and of predicates in filter expressions, in a way that might allow the processor to raise dynamic errors that the author intended to prevent.
See 2.4.5 Guarded Expressions
PR 254
The term "function conversion rules" used in 3.1 has been replaced by the term "coercion rules".
See 3.4 Coercion Rules
The coercion rules allow “relabeling” of a supplied atomic item where the required type is a derived atomic type: for example, it is now permitted to supply the value 3 when calling a function that expects an instance of xs:positiveInteger.
See 3.4 Coercion Rules
The value bound to a variable in a let clause is now converted to the declared type by applying the coercion rules.
See 4.13.3 Let Clause
The coercion rules are now used when binding values to variables (both global variable declarations and local variable bindings). This aligns XQuery with XSLT, and means that the rules for binding to variables are the same as the rules for binding to function parameters.
See 5.16 Variable Declaration
PR 284
Alternative syntax for conditional expressions is available: if (condition) { X }.
See 4.16 Conditional Expressions
PR 286
Element and attribute tests can include alternative names: element(chapter|section), attribute(role|class).
See 3.2.7 Node Types
The NodeTest in an AxisStep now allows alternatives: ancestor::(section|appendix)
See 3.2.7 Node Types
Element and attribute tests of the form element(N) and attribute(N) now allow N to be any NameTest, including a wildcard.
See 3.2.7.2 Element Types
See 3.2.7.3 Attribute Types
PR 324
String templates provide a new way of constructing strings: for example `{$greeting}, {$planet}!` is equivalent to $greeting || ', ' || $planet || '!'
See 4.9.2 String Templates
PR 326
Support for higher-order functions is now a mandatory feature (in 3.1 it was optional).
See 6 Conformance
PR 344
A for member clause is added to FLWOR expressions to allow iteration over an array.
See 4.13.2 For Clause
PR 364
Switch expressions now allow a case clause to match multiple atomic items.
See 4.18 Switch Expressions
PR 368
The concept of the context item has been generalized, so it is now a context value. That is, it is no longer constrained to be a single item.
See 2.2.2 Dynamic Context
See 5.17 Context Value Declaration
PR 433
Numeric literals can now be written in hexadecimal or binary notation; and underscores can be included for readability.
See 4.2.1.1 Numeric Literals
PR 483
The start clause in window expressions has become optional, as well as the when keyword and its associated expression.
See 4.13.4 Window Clause
PR 493
A new variable $err:map is available, capturing all error information in one place.
See 4.20 Try/Catch Expressions
PR 519
The rules for tokenization have been largely rewritten. In some cases the revised specification may affect edge cases that were handled in different ways by different 3.1 processors, which could lead to incompatible behavior.
See A.3 Lexical structure
PR 521
New abbreviated syntax is introduced (focus function) for simple inline functions taking a single argument. An example is fn { ../@code }
See 4.5.6 Inline Function Expressions
PR 587
Switch and typeswitch expressions can now be written with curly brackets, to improve readability.
See 4.18 Switch Expressions
See 4.21.2 Typeswitch
PR 603
The rules for reporting type errors during static analysis have been changed so that a processor has more freedom to report errors in respect of constructs that are evidently wrong, such as @price/@value, even though dynamic evaluation is defined to return an empty sequence rather than an error.
See 2.4.6 Implausible Expressions
See 4.6.4.3 Implausible Axis Steps
PR 606
Element and attribute tests of the form element(A|B) and attribute(A|B) are now allowed.
See 3.2.7.2 Element Types
See 3.2.7.3 Attribute Types
PR 635
The rules for the consistency of schemas imported by different query modules, and for consistency between imported schemas and those used for validating input documents, have been defined with greater precision. It is now recognized that these schemas will not always be identical, and that validation with respect to different schemas may produce different outcomes, even if the components of one are a subset of the components of the other.
See 5.11 Schema Import
PR 659
In previous versions the interpretation of location hints in import schema declarations was entirely at the discretion of the processor. To improve interoperability, XQuery 4.0 recommends (but does not mandate) a specific strategy for interpreting these hints.
See 5.11 Schema Import
PR 678
The comparand expression in a switch expression can be omitted, allowing the switch cases to be provided as arbitrary boolean expressions.
See 4.18 Switch Expressions
PR 682
The values true() and false() are allowed in function annotations, and negated numeric literals are also allowed.
See 5.18.4 Function Annotations
PR 691
Enumeration types are added as a new kind of ItemType, constraining the value space of strings.
See 3.2.6 Enumeration Types
PR 728
The syntax record(*) is allowed; it matches any map.
See 3.2.8.3 Record Types
PR 753
The default namespace for elements and types can now be declared to be fixed for a query module, meaning it is unaffected by a namespace declaration appearing on a direct element constructor.
See 4.12.1.2 Namespace Declaration Attributes
See 5.14 Default Namespace Declaration
PR 815
The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.
See 3.4 Coercion Rules
PR 820
The value bound to a variable in a for clause is now converted to the declared type by applying the coercion rules.
See 4.13.2 For Clause
PR 837
A deep lookup operator ?? is provided for searching trees of maps and arrays.
See 4.14.3 Lookup Expressions
PR 911
The coercion rules now allow any numeric type to be implicitly converted to any other, for example an xs:double is accepted where the required type is xs:double.
See 3.4 Coercion Rules
PR 943
A FLWOR expression may now include a while clause, which causes early exit from the iteration when a condition is encountered.
See 4.13.6 While Clause
PR 996
The value of a predicate in a filter expression can now be a sequence of integers.
See 4.4 Filter Expressions
PR 1031
An otherwise operator is introduced: A otherwise B returns the value of A, unless it is an empty sequence, in which case it returns the value of B.
See 4.17 Otherwise Expressions
PR 1071
In map constructors, the keyword map is now optional, so map { 0: false(), 1: true() } can now be written { 0: false(), 1: true() }, provided it is used in a context where this creates no ambiguity.
See 4.14.1.1 Map Constructors
PR 1125
Lookup expressions can now take a modifier (such as keys, values, or pairs) enabling them to return structured results rather than a flattened sequence.
See 4.14.3 Lookup Expressions
PR 1132
Choice item types (an item type allowing a set of alternative item types) are introduced.
See 3.2.5 Choice Item Types
PR 1163
Filter expressions for maps and arrays are introduced.
See 4.14.4 Filter Expressions for Maps and Arrays
PR 1181
The default namespace for elements and types can be set to the value ##any, allowing unprefixed names in axis steps to match elements with a given local name in any namespace.
See 2.2.1 Static Context
If the default namespace for elements and types has the special value ##any, then an unprefixed name in a NameTest acts as a wildcard, matching names in any namespace or none.
See 4.6.4.2 Node Tests
The default namespace for elements and types can be set to the value ##any, allowing unprefixed names in axis steps to match elements with a given local name in any namespace.
See 5.14 Default Namespace Declaration
PR 1197
The keyword fn is allowed as a synonym for function in function types, to align with changes to inline function declarations.
See 3.2.8.1 Function Types
In inline function expressions, the keyword function may be abbreviated as fn.
See 4.5.6 Inline Function Expressions
PR 1212
XQuery 3.0 included empty-sequence and item as reserved function names, and XQuery 3.1 added map and array. This was unnecessary since these names never appear followed by a left parenthesis at the start of an expression. They have therefore been removed from the list. New keywords introducing item types, such as record and enum, have not been included in the list.
See A.4 Reserved Function Names
PR 1217
Predicates in filter expressions for maps and arrays can now be numeric.
See 4.14.4 Filter Expressions for Maps and Arrays
PR 1249
A for key/value clause is added to FLWOR expressions to allow iteration over a map.
See 4.13.2 For Clause
PR 1250
Several decimal format properties, including minus sign, exponent separator, percent, and per-mille, can now be rendered as arbitrary strings rather than being confined to a single character.
See 2.2.1.2 Decimal Formats
See 5.10 Decimal Format Declaration
PR 1254
The rules concerning the interpretation of xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes have been tightened up.
See 4.25 Validate Expressions
PR 1265
The rules regarding the document-uri property of nodes returned by the fn:collection function have been relaxed.
See 2.2.2 Dynamic Context
PR 1342
The ordered { E } and unordered { E } expressions are retained for backwards compatibility reasons, but in XQuery 4.0 they are deprecated and have no useful effect.
See 4.15 Ordered and Unordered Expressions
The ordering mode declaration is retained for backwards compatibility reasons, but in XQuery 4.0 it is deprecated and has no useful effect.
See 5.7 Ordering Mode Declaration
PR 1344
Parts of the static context that were there purely to assist in static typing, such as the statically known documents, were no longer referenced and have therefore been dropped.
See 2.2.1 Static Context
The static typing option has been dropped.
See 2.3 Processing Model
The static typing feature has been dropped.
See 6 Conformance
PR 1361
The term atomic value has been replaced by atomic item.
See 2.1.2 Values
PR 1384
If a type declaration is present, the supplied values in the input sequence are now coerced to the required type. Type declarations are now permitted in XPath as well as XQuery.
See 4.19 Quantified Expressions
PR 1432
In earlier versions, the static context for the initializing expression excluded the variable being declared. This restriction has been lifted.
See 5.16 Variable Declaration
PR 1470
$err:stack-trace provides information about the current state of execution.
See 4.20 Try/Catch Expressions
PR 1496
The context value static type, which was there purely to assist in static typing, has been dropped.
See 2.2.1 Static Context
PR 1498
The EBNF operators ++ and ** have been introduced, for more concise representation of sequences using a character such as "," as a separator. The notation is borrowed from Invisible XML.
See 2.1 Terminology
The EBNF notation has been extended to allow the constructs (A ++ ",") (one or more occurrences of A, comma-separated, and (A ** ",") (zero or more occurrences of A, comma-separated.
See 2.1.1 Grammar Notation
The EBNF operators ++ and ** have been introduced, for more concise representation of sequences using a character such as "," as a separator. The notation is borrowed from Invisible XML.
See A.1 EBNF
See A.1.1 Notation
PR 1501
The coercion rules now apply recursively to the members of an array and the entries in a map.
See 3.4 Coercion Rules
PR 1532
Four new axes have been defined: preceding-or-self, preceding-sibling-or-self, following-or-self, and following-sibling-or-self.
See 4.6.4.1 Axes
PR 1577
The syntax record() is allowed; the only thing it matches is an empty map.
See 3.2.8.3 Record Types
PR 1686
With the pipeline operator ->, the result of an expression can be bound to the context value before evaluating another expression.
See 4.22 Pipeline operator
PR 1696
Parameter names may be included in a function signature; they are purely documentary.
See 3.2.8.1 Function Types
PR 1703
Ordered maps are introduced.
See 4.14.1 Maps
The order of key-value pairs in the map constructor is now retained in the constructed map.
See 4.14.1.1 Map Constructors
PR 1874
The coercion rules now reorder the entries in a map when the required type is a record type.
See 3.4 Coercion Rules
PR 1898
The rules for subtyping of document node types have been refined.
See 3.3.2.4.2 Subtyping Nodes: Document Nodes
PR 1914
A finally clause can be supplied, which will always be evaluated after the expressions of the try/catch clauses.
See 4.20 Try/Catch Expressions
PR 1942
Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables.
See 4.13.3 Let Clause
PR 1942
Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables.
See 4.13.3 Let Clause
PR 1956
Private variables declared in a library module are no longer required to be in the module namespace.
See 5.16 Variable Declaration
Private functions declared in a library module are no longer required to be in the module namespace.
See 5.18.2 Function Names
PR 1982
Whitespace is now required after the opening (# of a pragma. This is an incompatible change, made to ensure that an expression such as error(#err:XPTY0004) can be parsed as a function call taking a QName literal as its argument value.
See 4.26 Extension Expressions
PR 1991
Named record types used in the signatures of built-in functions are now available as standard in the static context.
See 2.2.1 Static Context
PR 2026
The module feature is no longer an optional feature; processing of library modules is now required.
See 6 Conformance
PR 2030
The technical details of how validation works have been moved to the Functions and Operators specification. The XQuery validate expression is now defined in terms of the new xsd-validator function.
See 4.25 Validate Expressions
PR 2055
Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables.
See 4.13.3 Let Clause
PR 2055
Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables.
See 4.13.3 Let Clause

XQuery 4.0: An XML Query Language

W3C Editor's Draft 23 February 2026

Abstract

Status of this Document

Dedication

4 Expressions

4.13 FLWOR Expressions

4.13.3 Let Clause

J Change Log (Non-Normative)