Please check the errata for any errors or issues reported since publication.
See also translations.
This document is also available in these non-normative formats: XML.
Copyright © 2000 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
XML is a versatile markup language, capable of labeling the information content of diverse data sources, including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is designed to be broadly applicable across many types of XML data sources.
A list of changes made since XQuery 3.1 can be found in J Change Log.
This is a draft prepared by the QT4CG (officially registered in W3C as the XSLT Extensions Community Group). Comments are invited.
The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).
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 |
ExprSingle | ::= | FLWORExpr |
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.
Most modern programming languages have support for collections of key/value pairs, which may be called maps, dictionaries, associative arrays, hash tables, keyed lists, or objects (these are not the same thing as objects in object-oriented systems). In XQuery 4.0, we call these maps. Most modern programming languages also support ordered lists of values, which may be called arrays, vectors, or sequences. In XQuery 4.0, we have both sequences and arrays. Unlike sequences, an array is an item, and can appear as an item in a sequence.
Note:
The XQuery 4.0 specification focuses on syntax provided for maps and arrays, especially constructors and lookup.
Some of the functionality typically needed for maps and arrays is provided by functions defined in Section 18 Processing mapsFO and Section 19 Processing arraysFO, including functions used to read JSON to create maps and arrays, serialize maps and arrays to JSON, combine maps to create a new map, remove map entries to create a new map, iterate over the keys of a map, convert an array to create a sequence, combine arrays to form a new array, and iterate over arrays in various ways.
A method call invokes a function held as the value of an entry in a map, supplying the map implicitly as the value of the first argument. [Issue 2143 4 August 2025]
A method call combines accessing a map M to look up an entry whose value is a function item F, and calling the function item F supplying the map M as the implicit value of the first argument.
For example, given the variable:
let $rectangle := {
'height': 3,
'width': 4,
'area': fn ($rect) {
$rect?height × $rect?width
},
'perimeter': fn ($rect) {
2 × ($rect?height + $rect?width)
},
'resize': fn ($rect, $factor) {
$rect
=> map:put('height', $rect?height × $factor)
=> map:put('width', $rect?width × $factor)
}
}The method call $rectangle ?> area() returns 12, while the method call $rectangle ?> perimeter() returns 14, and $rectangle ?> resize(2) returns a map representing a rectangle with height = 6 and width = 8.
An arity-one function can also be written as a focus function:
let $rectangle := {
'height': 3,
'width': 4,
'area': fn { ?height × ?width }
}The expression M ?> N(X, Y, ...) is by definition equivalent to:
for $map as map(*) in M
return ($map?N treat as function(*))
($map, X, Y, ...)(where $map is some otherwise unused variable name).
The argument list in a method call must not include an argument placeholder; that is, the call must not be a partial function application ([err:XPST0003]).
Note:
Implicit in this definition are the following rules:
The value of M must be a sequence of zero or more maps;
Each of those maps must have an entry with the key N (as an instance of xs:string, xs:untypedAtomic, or xs:anyURI);
The value of that entry must be a single function item;
That function item must have an arity equal to one plus the number of supplied arguments, and the signature of the function must allow a map to be supplied as the first argument.
The error codes raised if these conditions are not satisfied are exactly the same as if the expanded code were used directly.
Note:
Although methods mimic some of the capability of object-oriented languages, the functionality is more limited:
There is no encapsulation: the entries in a map are all publicly exposed.
There is no class hierarchy, and no inheritance or overriding.
Methods within a map can be removed or replaced in the same way as any other entries in the map.
Note:
Methods can be useful when there is a need to write inline recursive functions. For example:
let $lib := {
'product': fn($map as map(*), $in as xs:double*) {
if (empty( $in ))
then 1
else head($in) × $map ?> product(tail($in))
}
}
return $lib ?> product((1.2, 1.3, 1.4))In an environment that supports XPath but not XQuery, this mechanism can be used to define all the functions that a particular XPath expression needs to invoke, and these functions can be mutually recursive.
Note:
Methods are often useful in conjunction with named record types: see 5.20.3 Using Methods in Records.
In the example above, $rectangle ?> area(), $rectangle is typically a single map, and area is the key of one of the entries in the map, the value of the entry being a function item that takes the map as its implicit first argument. The method call $rectangle ?> area() first performs a map lookup ($rectangle?area) to select the function item, and then calls the function item, supplying the containing map as the first (and in this case only) argument.
Such calls can be chained. For example, $rectangle ?> resize(2) returns a rectangle that is twice the size of the original, so $rectangle ?> resize(2) ?> area() returns the area of the enlarged rectangle.
Note:
Note how the resize function is implemented using map:put, which ensures that the map entries holding function items (area, perimeter, and resize, are automatically present and unchanged in the modified map.
This kind of chaining extends to the case where a method returns zero or more maps. For example, suppose that rectangles are nested, and that $rectangle ?> contents() delivers a sequence of zero or more rectangles. Then the expression $rectangle ?> area() - sum($rectangle ?> contents() ?> area()) returns the difference between the area of the containing rectangle and the total area of the contained rectangles. This works because the dynamic function call $rectangle ?> contents() ?> area() applies the area function in each of the maps in the sequence returned by the expression $rectangle ?> contents().
A record type representing a rectangle containing nested rectangles might be defined in XQuery 4.0 like this:
declare record my:rectangle {
height as xs:double,
width as xs:double,
children as my:rectangle*
:= (),
area as fn($my:rectangle) as xs:double
:= fn{?height × ?width}
resize as fn($my:rectangle, xs:double) as my:rectangle
:= fn($rect, $factor) {
$rect => map:put('height', $rect?height × $factor)
=> map:put('width', $rect?width × $factor0
=> map:put('children', $rect?children ?> resize($factor)
}
contents as fn($my:rectangle) as my:rectangle*
:= fn{?children}
}declare record my:rectangle (
height as xs:double,
width as xs:double,
children as my:rectangle*
:= (),
area as fn(my:rectangle) as xs:double
:= fn{?height × ?width},
resize as fn(my:rectangle, xs:double) as my:rectangle
:= fn($rect, $factor) {
$rect => map:put('height', $rect?height × $factor)
=> map:put('width', $rect?width × $factor)
=> map:put('children', $rect?children ?> resize($factor))
},
contents as fn(my:rectangle) as my:rectangle*
:= fn{?children}
);A query can be assembled from one or more fragments called modules. [Definition: A module is a fragment of XQuery code that conforms to the Module grammar and can independently undergo the static analysis phase described in 2.3.3 Expression Processing. Each module is either a main module or a library module.]
[Definition: A main module consists of a Prolog followed by a Query Body.] A query has exactly one main module. In a main module, the Query Body is evaluated with respect to the static and dynamic contexts of the main module in which it is found, and its value is the result of the query.
[Definition: A module that does not contain a Query Body is called a library module. A library module consists of a module declaration followed by a Prolog.] A library module cannot be evaluated directly; instead, it provides function and variable declarations that can be imported into other modules.
The XQuery syntax does not allow a module to contain both a module declaration and a Query Body.
[Definition: A Prolog is a series of declarations and imports that define the processing environment for the module that contains the Prolog.] Each declaration or import is followed by a semicolon. A Prolog is organized into two parts.
The first part of the Prolog consists of setters, imports, namespace declarations, and default namespace declarations. [Definition: Setters are declarations that set the value of some property that affects query processing, such as construction mode or default collation.] Namespace declarations and default namespace declarations affect the interpretation of lexical QNames within the query. Imports are used to import definitions from schemas and modules. [Definition: The target namespace of a module is the namespace of the objects (such as elements or functions) that it defines. ]
The second part of the Prolog consists of declarations of variables, functions, and options. These declarations appear at the end of the Prolog because they may be affected by declarations and imports in the first part of the Prolog.
[Definition: The Query Body, if present, consists of an expression that defines the result of the query.] Evaluation of expressions is described in 4 Expressions. A module can be evaluated only if it has a Query Body.
Although item type declarations, as described in 5.19 Item Type Declarations, can be used to give names to record types as well as any other item type, named record types as described in this section provide a more concise syntax, plus additional functionality. In particular:
Named record types can be recursive.
Named record types implicitly create a constructor function that can be used to create instances of the record type.
A field in a named record type can be a function that has implicit access to the record on which it is defined, rather like methods in object-oriented languages.
The syntax is as follows:
NamedRecordTypeDecl | ::= | "declare" Annotation* "record" EQName "(" (ExtendedFieldDeclaration ** ",") ExtensibleFlag? ")" |
Annotation | ::= | "%" EQName ("(" (AnnotationValue ++ ",") ")")? |
EQName | ::= | QName | URIQualifiedName |
ExtendedFieldDeclaration | ::= | FieldDeclaration (":=" ExprSingle)? |
FieldDeclaration | ::= | FieldName "?"? ("as" SequenceType)? |
FieldName | ::= | NCName | StringLiteral |
StringLiteral | ::= | AposStringLiteral | QuotStringLiteral |
| /* ws: explicit */ | ||
SequenceType | ::= | ("empty-sequence" "(" ")") |
ExprSingle | ::= | FLWORExpr |
ExtensibleFlag | ::= | "," "*" |
A named record declaration serves as both a named item type and as a function definition, and it therefore inherits rules from both these roles. In particular:
Its name must not be the same as the name of any other named item type, or any generalized atomic type, that is present in the same static context [err:XQST0048].
If the declaration is public and is within a library module, then its name must be in the target namespace of the library module [err:XQST0048].
As a function, it must not have an arity range that overlaps the arity range of any other function declaration having the same name in the same static context.
The order of field declarations is significant, because it determines the order of arguments in a call to the constructor function.
The fields must have distinct names. [err:XPST0021]
In order to work as both a record type and a function declaration, the names of the fields must be simple NCNames in no namespace; the names must not be written as string literals [err:XPST0003].
Note:
This is described here as a semantic constraint, but an implementation might choose to impose it at the level of the grammar.
If an initializing expression is present in an ExtendedFieldDeclaration, it must follow the rules for the initializing expression of a parameter in a function declaration, given in 5.18.3 Function Parameters. In particular, if any field has an initializing expression then all following fields must have an initializing expression.
Any annotations that are present, such as %public or %private, apply both to the item type declaration and to the function declaration.
Named record declarations are useful in conjunction with method calls, described in 4.14.4 Method Calls. For example, given the declaration:
declare record geom:rectangle(
width as xs:double,
height as xs:double,
area as fn($rect as map(*)) as xs:double := fn($rect) {
$rect -> ?width × ?height
},
perimeter as fn($rect as map(*)) as xs:double := fn($rect) {
$rect -> 2 × (?width + ?height)
},
expand as fn($rect as map(*), $factor as xs:double) as geom:rectangle := fn() {
$rect -> geom:rectangle(?width × $factor, ?height × $factor)
}
);declare record my:rectangle (
height as xs:double,
width as xs:double,
area as fn(my:rectangle) as xs:double
:= fn{?height × ?width},
resize as fn(my:rectangle, xs:double) as my:rectangle
:= fn($rect, $factor) {
$rect => map:put('height', $rect?height × $factor)
=> map:put('width', $rect?width × $factor)
}
);The following expression constructs a rectangle and calculates its area:
let $box := geom:rectangle(3, 2)
return $box ?> area()let $box := my:rectangle(3, 2)
return $box ?> area()The following expands the dimensions of the rectangle and calculates the perimeter of the result:
let $box := geom:rectangle(3, 2)
return $box ?> expand(2) ?> perimeter()let $box := my:rectangle(3, 2)
return $box ?> expand(2) ?> perimeter()Note:
There is nothing to stop a user constructing an instance of geom:rectanglemy:rectangle in which the area entry holds some different function: while the syntax imitates that of object-oriented languages, there is no encapsulation.