XQuery 4.0: An XML Query Language

2 Basics

2.1 Terminology

Changes in 4.0 ⬇ ⬆

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. [Issue 1366 PR 1498]

The basic building block of XQuery 4.0 is the expression, which is a string of [Unicode] characters; the version of Unicode to be used is implementation-defined. The language provides several kinds of expressions which may be constructed from keywords, symbols, and operands. In general, the operands of an expression are other expressions. XQuery 4.0 allows expressions to be nested with full generality. (However, unlike a pure functional language, it does not allow variable substitution if the variable declaration contains construction of new nodes.)

Note:

This specification contains no assumptions or requirements regarding the character set encoding of strings of [Unicode] characters.

Like XML, XQuery 4.0 is a case-sensitive language. Keywords in XQuery 4.0 use lower-case characters and are not reserved—that is, names in XQuery 4.0 expressions are allowed to be the same as language keywords, except for certain unprefixed function-names listed in A.4 Reserved Function Names.

In this specification the phrases must, must not, should, should not, may, required, and recommended, when used in normative text and rendered in small capitals, are to be interpreted as described in [RFC2119].

Certain aspects of language processing are described in this specification as implementation-defined or implementation-dependent.

[Definition: Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementer for each particular implementation.]
[Definition: Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementer for any particular implementation.]

2.1.4 Namespaces and QNames

Changes in 4.0 ⬇ ⬆

In XQuery 4.0, an initial set of namespace bindings is prescribed for the static context. [Issues 485 2178 PR 487]

[Definition: A namespace binding is a pair comprising a namespace prefix (which is either an xs:NCName or empty), and a namespace URI.]

Element nodes have a property called in-scope namespaces. [Definition: The in-scope namespaces property of an element node is a set of namespace bindings, each of which associates a namespace prefix with a URI.] For a given element, one namespace binding may have an empty prefix; the URI of this namespace binding is referred to as the default in-scope namespace for the element.

Note:

In [XML Path Language (XPath) Version 1.0], the in-scope namespaces of an element node are represented by a collection of namespace nodes arranged on a namespace axis, which is optional and deprecated in [XPath 4.0]. XQuery does not support the namespace axis and does not represent namespace bindings in the form of nodes.

However, where other specifications such as [XSLT and XQuery Serialization 4.0] refer to namespace nodes, these nodes may be synthesized from the in-scope namespaces of an element node by interpreting each namespace binding as a namespace node. An application that needs to create a set of namespace nodes to represent these bindings for an element bound to $e can do so using the following code.

for key $k value $v in in-scope-namespaces($e)
return namespace {$k}{$v}

[Definition: The default in-scope namespace of an element node] is the namespace URI to which the empty prefix is bound in the element’s in-scope namespaces. In the absence of an explicit binding for the empty prefix, the default in-scope namespace is absent^DM.

[Definition: An expanded QName is a triple: its components are a prefix, a local name, and a namespace URI. In the case of a name in no namespace, the namespace URI and prefix are both absent. In the case of a name in the default namespace, the prefix is absent.] When comparing two expanded QNames, the prefixes are ignored: the local name parts must be equal under the Unicode codepoint collation (Section 5.3.1 Collations^FO), and the namespace URI parts must either both be absent, or must be equal under the Unicode codepoint collation.

Note:

The datum^DM of an atomic item of type xs:QName is an expanded QName. However, the term expanded QName is also used for the names of constructs such as functions, variables, and types that are not themselves atomic items.

In the XQuery 4.0 grammar, QNames representing the names of elements, attributes, functions, variables, types, or other such constructs are written as instances of the grammatical production EQName.

`EQName`	::=	`QName \| URIQualifiedName`
`URIQualifiedName`	::=	`BracedURILiteralNCName`
		/* ws: explicit */
`BracedURILiteral`	::=	`"Q" "{" (PredefinedEntityRef \| CharRef \| [^&{}])* "}"`
		/* ws: explicit */

The EQName production allows a QName to be written in one of three ways:

local-name only (for example, invoice).
A name written in this form has no prefix, and the rules for determining the namespace depend on the context in which the name appears: the various rules used are summarized in 2.1.5 Expanding Lexical QNames. This form is a lexical QName.
prefix plus local-name (for example, my:invoice).
In this case the prefix and local name of the QName are as written, and the namespace URI is inferred from the prefix by examining the statically known namespaces in the static context where the QName appears; the context must include a binding for the prefix. This form is a lexical QName.
URI plus local-name (for example, Q{http://example.com/ns}invoice).
In this case the local name and namespace URI are as written, and the prefix is absent. This way of writing a QName is context-free, which makes it particularly suitable for use in queries that are generated by software. This form is a URIQualifiedName. If the BracedURILiteral has no content (for example, Q{}invoice) then the namespace URI of the QName is absent.

[Definition: A lexical QName is a name that conforms to the syntax of the QName production].

The namespace URI value in a URIQualifiedName is whitespace normalized according to the rules for the xs:anyURI type in Section 3.2.17 anyURI ^XS1-2 or Section 3.3.17 anyURI ^XS11-2. It is a static error [err:XQST0070] if the namespace URI for an EQName is http://www.w3.org/2000/xmlns/.

Here are some examples of EQNames:

pi is a lexical QName without a namespace prefix.
math:pi is a lexical QName with a namespace prefix.
Q{http://www.w3.org/2005/xpath-functions/math}pi specifies the namespace URI using a BracedURILiteral; it is not a lexical QName.

This document uses the following namespace prefixes to represent the namespace URIs with which they are listed. Although these prefixes are used within this specification to refer to the corresponding namespaces, not all of these bindings will necessarily be present in the static context of every expression, and authors are free to use different prefixes for these namespaces, or to bind these prefixes to different namespaces.

xml: http://www.w3.org/XML/1998/namespace
xs: http://www.w3.org/2001/XMLSchema
xsi: http://www.w3.org/2001/XMLSchema-instance
fn: http://www.w3.org/2005/xpath-functions
array: http://www.w3.org/2005/xpath-functions/array
map: http://www.w3.org/2005/xpath-functions/map
math: http://www.w3.org/2005/xpath-functions/math
err: http://www.w3.org/2005/xqt-errors (see 2.4.2 Identifying and Reporting Errors).
local: http://www.w3.org/2005/xquery-local-functions (see 5.18 Function Declarations.)
output: http://www.w3.org/2010/xslt-xquery-serialization
xq: http://www.w3.org/2012/xquery

In XQuery 4.0, the above namespace bindings are by default included in the statically known namespaces of the static context of every query module; however, these bindings can be overridden in the query prolog.

[Definition: Within this specification, the term URI refers to a Universal Resource Identifier as defined in [RFC3986] and extended in [RFC3987] with the new name IRI.] The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as “Base URI” that are defined or referenced across the whole family of XML specifications.

Note:

In most contexts, processors are not required to raise errors if a URI is not lexically valid according to [RFC3986] and [RFC3987]. See 2.5.5 URI Literalsand 4.12.1.2 Namespace Declaration Attributes for details.

2.2 Expression Context

[Definition: The expression context for a given expression consists of all the information that can affect the result of the expression.]

This information is organized into two categories called the static context and the dynamic context.

2.2.1 Static Context

Changes in 4.0 ⬇ ⬆

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. [Issue 296 PR 1181 30 April 2024]
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. [Issue 1343 PR 1344 23 September 2024]
The context value static type, which was there purely to assist in static typing, has been dropped. [Issue 1495 PR 1496 29 October 2024]
Named record types used in the signatures of built-in functions are now available as standard in the static context. [Issue 835 PR 1991 11 May 2025]

[Definition: 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.

The individual components of the static context are described below.

In XQuery 4.0, the static context for an expression is largely defined in the query prolog of a module: see 5 Modules and Prologs. Declarations in the prolog, such as variable declarations, function declarations, and decimal format declarations populate the static context for expressions appearing within the module. In some cases (but not all) these declarations may affect the static context for expressions that precede the relevant declaration. The static context can also be affected by declarations in other modules that are referenced using an import module declaration: see 5.12 Module Import.

In addition, some expressions modify the static context for their subexpressions. The most obvious example is in-scope variables (a FLWORExpr declares bindings of local variables that are available for reference within subsequent clauses of the expression). A further example is the statically known namespaces: an element constructor may contain namespace declarations such as xmlns:p="some_uri" which cause additional namespace prefixes to be available within the content of the element constructor.

Appendix B.1 Static Context Components gives an overview of the components in the static context and the way they are initialized.

Some components of the static context, but not all, also affect the dynamic semantics of expressions. For example, casting of a string such as "xbrl:xbrl" to an xs:QName might expand the prefix xbrl to the namespace URI http://www.xbrl.org/2003/instance using the statically known namespaces from the static context; since the input string "xbrl:xbrl" is in general not known until execution time (it might be read from a source document), this means that the values of the statically known namespaces must be available at execution time.

[Definition: XPath 1.0 compatibility mode.This component must be set by all host languages that include XPath 3.1 as a subset, indicating whether rules for compatibility with XPath 1.0 are in effect. XQuery sets the value of this component to false. ]
[Definition: Statically known namespaces. This is a mapping from prefix to namespace URI that defines all the namespaces that are known during static processing of a given expression.]
The URI value is whitespace normalized according to the rules for the xs:anyURI type in Section 3.2.17 anyURI ^XS1-2 or Section 3.3.17 anyURI ^XS11-2.
The statically known namespaces may include a binding for the zero-length prefix: however, this is used only by the constructed element namespace rule.
Note the difference between in-scope namespaces, which is a dynamic property of an element node, and statically known namespaces, which is a static property of an expression.
Some namespaces are predefinedpredeclared (see 2.1.4 Namespaces and QNames); additional namespaces can be added to the statically known namespaces by namespace declarations, schema imports, or module imports in a Prolog, by a module declaration, and by namespace declaration attributes in direct element constructors.
[Definition: Default namespace for elements and types. This is either a namespace URI, or the special value "##any", or absent^DM. This indicates how unprefixed QNames are interpreted when they appear in a position where an element name or type name is expected.]
- If the value is set to a namespace URI, this namespace is used for any such unprefixed QName. The URI value is whitespace-normalized according to the rules for the xs:anyURI type in Section 3.2.17 anyURI ^XS1-2 or Section 3.3.17 anyURI ^XS11-2.
- The special value "##any" indicates that:
  - When an unprefixed QName is used as a name test for selecting named elements in an axis step, the name test will match an element having the specified local name, in any namespace or none.
  - When an unprefixed QName is used in a context where a type name is expected (but not as a function name), the default namespace is the xs namespace, http://www.w3.org/2001/XMLSchema.
  - In any other context, an unprefixed QName represents a name in no namespace.
- If the value is absent^DM, an unprefixed QName representing an element or type name is interpreted as being in no namespace.
[Definition: Default function namespace. This is either a namespace URI, or absent^DM. The namespace URI, if present, is used for any unprefixed QName appearing in a position where a function name is expected.] The URI value is whitespace-normalized according to the rules for the xs:anyURI type in Section 3.2.17 anyURI ^XS1-2 or Section 3.3.17 anyURI ^XS11-2
In its simplest form its value is simply a whitespace-normalized xs:anyURI value (most commonly, the URI http://www.w3.org/2005/xpath-functions) to be used as the default namespace for unprefixed function names. However, the use of a more complex algorithm is not precluded, for example an algorithm which searches multiple namespaces for a matching name.
In XQuery, a default function namespace can be declared in the prolog in a default function namespace declaration (see 5.14 Default Namespace Declaration); in the absence of such a declaration, the namespace http://www.w3.org/2005/xpath-functions is used.
[Definition: In-scope schema definitions is a generic term for all the element declarations, attribute declarations, and schema type definitions that are in scope during static analysis of an expression.] It includes the following three parts:
- [Definition: In-scope schema types. Each schema type definition is identified either by an expanded QName (for a named type) or by an implementation-dependent type identifier (for an anonymous type). The in-scope schema types include the predefined schema types described in 3.5 Schema Types. If the Schema Aware Feature is supported, in-scope schema types also include all type definitions found in imported schemas. ]
- [Definition: In-scope element declarations. Each element declaration is identified either by an expanded QName (for a top-level element declaration) or by an implementation-dependent element identifier (for a local element declaration). If the Schema Aware Feature is supported, in-scope element declarations include all element declarations found in imported schemas. ] An element declaration includes information about the element’s substitution group affiliation.
  [Definition: Substitution groups are defined in Section 2.2.2.2 Element Substitution Group ^XS1-1 and Section 2.2.2.2 Element Substitution Group ^XS11-1. Informally, the substitution group headed by a given element (called the head element) consists of the set of elements that can be substituted for the head element without affecting the outcome of schema validation.]
- [Definition: In-scope attribute declarations. Each attribute declaration is identified either by an expanded QName (for a top-level attribute declaration) or by an implementation-dependent attribute identifier (for a local attribute declaration). If the Schema Aware Feature is supported, in-scope attribute declarations include all attribute declarations found in imported schemas. ]
[Definition: In-scope variables. This is a mapping from expanded QNames to sequence types. It defines the set of variables that are available for reference within an expression. The expanded QName is the name of the variable, and the type is the static type of the variable.]
Variable declarations in a Prolog are added to in-scope variables. An expression that binds a variable extends the in-scope variables, within the scope of the variable, with the variable and its type. Within the body of an inline function expression or user-defined function, the in-scope variables are extended by the names and types of the function parameters.
The static type of a variable may either be declared in a query or inferred by static type inference as discussed in 2.3.3.1 Static Analysis Phase.
[Definition: In-scope named item types. This is a mapping from expanded QNames to named item types.]
[Definition: A named item type is an ItemType identified by an expanded QName.]
Named item types serve two purposes:
- They allow frequently used item types, especially complex item types such as record types, to be given simple names, to avoid repeating the definition every time it is used.
- They allow the definition of recursive types, which are useful for describing recursive data structures such as lists and trees. For details see 3.2.8.3.1 Recursive Record Types.
Certain named item types (typically item types used in the signatures of built-in functions) are always available in the static context. These are defined in Section C Built-in named record types^FO.
Note:
In XQuery, named item types can be declared in the Query Prolog.
[Definition: Statically known function definitions. This is a set of function definitions.]
Function definitions are described in 2.2.1.1 Function Definitions.
[Definition: Statically known collations. This is an implementation-defined mapping from URI to collation. It defines the names of the collations that are available for use in processing queries and expressions.] [Definition: A collation is a specification of the manner in which strings and URIs are compared and, by extension, ordered. For a more complete definition of collation, see Section 5.3 Comparison of strings^FO.]
[Definition: Construction mode. The construction mode governs the behavior of element and document node constructors. If construction mode is preserve, the type of a constructed element node is xs:anyType, and all attribute and element nodes copied during node construction retain their original types. If construction mode is strip, the type of a constructed element node is xs:untyped; all element nodes copied during node construction receive the type xs:untyped, and all attribute nodes copied during node construction receive the type xs:untypedAtomic.]
[Definition: Default order for empty sequences. This component controls the processing of empty sequences and NaN values as ordering keys in an order by clause in a FLWOR expression, as described in 4.13.9 Order By Clause.] Its value may be greatest or least.
[Definition: Boundary-space policy. This component controls the processing of boundary whitespace by direct element constructors, as described in 4.12.1.4 Boundary Whitespace.] Its value may be preserve or strip.
[Definition: Copy-namespaces mode. This component controls the in-scope namespaces property that is assigned when an existing element node is copied by an element constructor, as described in 4.12.1 Direct Element Constructors. Its value consists of two parts: preserve or no-preserve, and inherit or no-inherit.]
[Definition: Static Base URI. This is an absolute URI, used to resolve relative URIs during static analysis. ] For example, it is used to resolve module location URIs in XQuery, and the URIs in xsl:import and xsl:include in XSLT. All expressions within a module have the same static base URI. The Static Base URI can be set using a base URI declaration.
Relative URI references are resolved as described in 2.5.6 Resolving a Relative URI Reference.
At execution time, relative URIs supplied to functions such as fn:doc are resolved against the Executable Base URI, which may or may not be the same as the Static Base URI.
[Definition: Statically known decimal formats. This is a mapping from QNames to decimal formats, with one default format that has no visible name, referred to as the unnamed decimal format. Each format is available for use when formatting numbers using the fn:format-number function.]
Decimal formats are described in 2.2.1.2 Decimal Formats.

B Context Components

The tables in this section describe how values are assigned to the various components of the static context and dynamic context.

B.1 Static Context Components

Changes in 4.0 ⬆

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. [Issue 1343 ]

The following table describes the components of the static context. The following aspects of each component are described:

Default initial value: This is the initial value of the component if it is not overridden or augmented by the implementation or by a query.
Can be overwritten or augmented by implementation: Indicates whether an XQuery implementation is allowed to replace the default initial value of the component by a different, implementation-defined value and/or to augment the default initial value by additional implementation-defined values.
Can be overwritten or augmented by prolog: Indicates whether there are prolog declarations that can replace and/or augment the initial value provided by default or by the implementation.
Can be overwritten or augmented by expressions: Indicates whether there are expressions that can replace and/or augment the value of the component for their subexpressions.
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.3.6 Consistency Constraints.

Static Context Components
Component	Default initial value	Can be overwritten or augmented by implementation?	Can be overwritten or augmented by prolog?	Can be overwritten or augmented by expressions?	Consistency rules
Statically known namespaces	`fn`, `xml`, `xs`, `xsi`, `local`See 2.1.4 Namespaces and QNamesfnSee, xml, xs, xsi, local2.1.4 Namespaces and QNames	overwriteable and augmentable (except for `xml`)	overwriteable and augmentable by 5.13 Namespace Declaration	overwriteable and augmentable by element constructor	Only one namespace can be assigned to a given prefix per lexical scope.
Default element/type namespace	no namespace	overwriteable	overwriteable by 5.14 Default Namespace Declaration	overwriteable by element constructor	Only one default namespace per lexical scope.
In-scope variables	none	augmentable	overwriteable and augmentable by 5.16 Variable Declaration and 4.5.6 Inline Function Expressions, augmentable by 5.12 Module Import	overwriteable and augmentable by variable-binding expressions	Only one definition per variable per lexical scope.
Context value static type	item()	overwriteable	overwriteable by 5.17 Context Value Declaration	overwriteable by expressions that set the context value	None.
Ordering mode	`ordered`	overwriteable	overwriteable by 5.7 Ordering Mode Declaration	overwriteable by expression	Value must be `ordered` or `unordered`.
Default function namespace	`fn`	overwriteable (not recommended)	overwriteable by 5.14 Default Namespace Declaration	no	None.
In-scope schema types	built-in types in `xs`	augmentable	augmentable by 5.11 Schema Import	no	Only one definition per global or local type.
In-scope element declarations	none	augmentable	augmentable by 5.11 Schema Import	no	Only one definition per global or local element name.
In-scope attribute declarations	none	augmentable	augmentable by 5.11 Schema Import	no	Only one definition per global or local attribute name.
Statically known function signatures	the signatures of the system functions	augmentable	augmentable by 5.12 Module Import and by 5.18 Function Declarations; augmentable by 5.11 Schema Import (which adds constructor functions for user-defined types)	no	Each function must have a unique expanded QName and number of arguments.
Default collation	Unicode codepoint collation	overwriteable	overwriteable by 5.4 Default Collation Declaration	no	None.
Construction mode	`preserve`	overwriteable	overwriteable by 5.6 Construction Declaration	no	Value must be `preserve` or `strip`.
Default order for empty sequences	implementation-defined	overwriteable	overwriteable by 5.8 Empty Order Declaration	no	Value must be `greatest` or `least`.
Boundary-space policy	`strip`	overwriteable	overwriteable by 5.3 Boundary-space Declaration	no	Value must be `preserve` or `strip`.
Copy-namespaces mode	`inherit, preserve`	overwriteable	overwriteable by 5.9 Copy-Namespaces Declaration	no	Value consists of `inherit` or `no-inherit`, and `preserve` or `no-preserve`.
Static Base URI	See rules in 5.5 Base URI Declaration	overwriteable	overwriteable by 5.5 Base URI Declaration	no	Value must be a valid lexical representation of the type xs:anyURI.
Statically known decimal formats	the default (unnamed) decimal format, which has an implementation-dependent value	augmentable	augmentable, using decimal format declarations	no	each QName uniquely identifies a decimal format
Statically known collations	only the default collation	augmentable	no	no	Each URI uniquely identifies a collation.
XPath 1.0 Compatibility Mode	`false`	no	no	no	Must be `false`.

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
PR 691 2154
Enumeration types are added as a new kind of ItemType, constraining the value space of strings.
See 3.2.6 Enumeration Types
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
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
Operator is-not is introduced, as a complement to the operator is.
See 4.10.3 GNode Comparisons
Operators precedes and follows are introduced as synonyms for operators << and >>.
See 4.10.3 GNode 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
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
PR 254 2050
The supplied context value is now coerced to the required type specified in the main module using the coercion rules.
See 5.17 Context Value 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 682 TODO
The values true() and false() are allowed in function annotations, as well as negated numeric literals and QName literals.
See 5.18.4 Function Annotations
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
Path expressions are extended to handle JNodes (found in trees of maps and arrays) as well as XNodes (found in trees representing parsed XML).
See 4.6 Path Expressions
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.
See 4.14.4 Method Calls
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
See 4.11 Logical 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 487
In XQuery 4.0, an initial set of namespace bindings is prescribed for the static context.
See 2.1.4 Namespaces and QNames
PR 487
In XQuery 4.0, an initial set of namespace bindings is prescribed for the static context.
See 2.1.4 Namespaces and QNames
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.6 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 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 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:decimal.
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 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.5 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.5 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.3 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.5.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 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 2031
The terms XNode and JNode are introduced; the existing term node remains in use as a synonym for XNode where the context does not specify otherwise.
See 2.1.3 Values
JNodes are introduced
See 3.2.9 Generalized Node Types
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 2094
A general expression is allowed within a map constructor; this facilitates the creation of maps in which the presence or absence of particular keys is decided dynamically.
See 4.14.1.1 Map Constructors
PR 2115
This section describes and formalizes a convention that was already in use, but not explicitly stated, in earlier versions of the specification.
See 2.1.2 Expression Names
PR 2134
The lookup operator ? can now be followed by an arbitrary literal, for cases where keys are items other than integers or NCNames. It can also be followed by a variable reference or a context value reference.
See 4.14.3 Lookup Expressions

XQuery 4.0: An XML Query Language

W3C Editor's Draft 23 February 2026

Abstract

Status of this Document

Dedication

2 Basics

2.1 Terminology

2.1.4 Namespaces and QNames

2.2 Expression Context

2.2.1 Static Context

B Context Components

B.1 Static Context Components

J Change Log (Non-Normative)