View Old View New View Both View Only Previous Next

This draft contains only sections that have differences from the version that it modified.

W3C

XQuery 4.0: An XML Query Language

W3C Editor's Draft 23 February 2026

This version:
https://qt4cg.org/specifications/xquery-40/
Most recent version of XQuery:
https://qt4cg.org/specifications/xquery-40/
Most recent Recommendation of XQuery:
https://www.w3.org/TR/2017/REC-xquery-31-20170321/
Editor:
Michael Kay, Saxonica <mike@saxonica.com>

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.

Abstract

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.

Status of this Document

This is a draft prepared by the QT4CG (officially registered in W3C as the XSLT Extensions Community Group). Comments are invited.

Dedication

The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).

2 Basics

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 ⬇ ⬆

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

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

  3. The context value static type, which was there purely to assist in static typing, has been dropped.   [Issue 1495 PR 1496 29 October 2024]

[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 in limited circumstances because the rules for resolving unprefixed QNames depend on how such a name is used.

    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 predefined; 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 absentDM. 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 absentDM, 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 absentDM. 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 variables. This is a mapping from expanded QName to type. 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 QName 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.

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

  • [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 namespace bindings that are 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.

3 Types

As noted in 2.1.2 Values, every value in XQuery 4.0 is regarded as a sequence of zero, one, or more items. The type system of XQuery 4.0, described in this section, classifies the kinds of value that the language can handle, and the operations permitted on different kinds of value.

The type system of XQuery 4.0 is related to the type system of [XML Schema 1.0] or [XML Schema 1.1] in two ways:

This chapter of the specification starts by defining sequence types and item types, which describe the range of values that can be bound to variables, used in expressions, or passed to functions. It then describes how these relate to schema types, that is, the simple and complex types defined in an XSD schema.

Note:

In many situations the terms item type and sequence type are used interchangeably to refer either to the type itself, or to the syntactic construct that designates the type: so in the expression $x instance of xs:string*, the construct xs:string* uses the SequenceType syntax to designate a sequence type whose instances are sequences of strings. When more precision is required, the specification is careful to use the terms item type and sequence type to refer to the actual types, while using the production names ItemType and SequenceType to refer to the syntactic designators of these types.

3.2 Item Types

[Definition: An item type is a type that can be expressed using the ItemType syntax, which forms part of the SequenceType syntax. Item types match individual items.]

Note:

While this definition is adequate for the purpose of defining the syntax of XQuery 4.0, it ignores the fact that there are also item types that cannot be expressed using XQuery 4.0 syntax: specifically, item types that reference an anonymous simple type or complex type defined in a schema. Such types can appear as type annotations on nodes following schema validation.

In most cases, the set of items matched by an item type consists either exclusively of atomic items, exclusively of nodes, or exclusively of function itemsDM. Exceptions include the generic types item(), which matches all items, xs:error, which matches no items, and choice item types, which can match any combination of types.

[Definition: An item type designator is a syntactic construct conforming to the grammar rule ItemType. An item type designator is said to designate an item type.]

Note:

Two item type designators may designate the same item type. For example, element() and element(*) are equivalent, as are attribute(A) and attribute(A, xs:anySimpleType).

Lexical QNames appearing in an item type designator(other than within a function assertion) have their prefixes expanded to namespace URIs by means of the statically known namespaces and (where applicable) the default namespace for elements and types. Equality of QNames is defined by the eq operator.

ItemType::=AnyItemTest | TypeName | KindTest | FunctionType | MapType | ArrayType | RecordType | EnumerationType | ChoiceItemType
AnyItemTest::="item" "(" ")"
TypeName::=EQName
EQName::=QName | URIQualifiedName
KindTest::=DocumentTest
| ElementTest
| AttributeTest
| SchemaElementTest
| SchemaAttributeTest
| PITest
| CommentTest
| TextTest
| NamespaceNodeTest
| AnyKindTest
DocumentTest::="document-node" "(" (ElementTest | SchemaElementTest | NameTestUnion)? ")"
ElementTest::="element" "(" (NameTestUnion ("," TypeName "?"?)?)? ")"
SchemaElementTest::="schema-element" "(" ElementName ")"
NameTestUnion::=(NameTest ++ "|")
NameTest::=EQName | Wildcard
Wildcard::="*"
| (NCName ":*")
| ("*:" NCName)
| (BracedURILiteral "*")
/* ws: explicit */
AttributeTest::="attribute" "(" (NameTestUnion ("," TypeName)?)? ")"
SchemaAttributeTest::="schema-attribute" "(" AttributeName ")"
PITest::="processing-instruction" "(" (NCName | StringLiteral)? ")"
StringLiteral::=AposStringLiteral | QuotStringLiteral
/* ws: explicit */
CommentTest::="comment" "(" ")"
TextTest::="text" "(" ")"
NamespaceNodeTest::="namespace-node" "(" ")"
AnyKindTest::="node" "(" ")"
FunctionType::=Annotation* (AnyFunctionType
| TypedFunctionType)
MapType::=AnyMapType | TypedMapType
ArrayType::=AnyArrayType | TypedArrayType
RecordType::=AnyRecordType | TypedRecordType
EnumerationType::="enum" "(" (StringLiteral ++ ",") ")"
ChoiceItemType::="(" (ItemType ++ "|") ")"

This section defines the syntax and semantics of different ItemTypes in terms of the values that they match.

Note:

For an explanation of the EBNF grammar notation (and in particular, the operators ++ and **), see A.1 EBNF.

An item type designator written simply as an EQName (that is, a TypeName) is interpreted as follows:

  1. If the name is written as a lexical QName, then it is expanded using the in-scope namespaces in the static context. If the name is an unprefixed NCName, then it is expanded according to the default namespace for elements and types.

  2. If the name matches a named item type in the static context, then it is taken as a reference to the corresponding item type. The rules that apply are the rules for the expanded item type definition.

  3. Otherwise, it must match the name of a type in the in-scope schema types in the static context: specifically, an atomic type or a pure union type. See 3.5 Schema Types for details.

    Note:

    A name in the xs namespace will always fall into this category, since the namespace is reserved. See 2.1.3 Namespaces and QNames.

  4. If the name cannot be resolved to a type, a static error is raised [err:XPST0051].

3.2.8 Function, Map, and Array Types

The following sections describe the syntax for item types for functions, including arrays and maps.

The subtype relation among these types is described in the various subsections of 3.3.2 Subtypes of Item Types.

3.2.8.1 Function Types

Changes in 4.0 ⬇ ⬆

  1. The keyword fn is allowed as a synonym for function in function types, to align with changes to inline function declarations.  [Issue 1192 PR 1197 21 May 2024]

  2. The terms FunctionType, ArrayType, MapType, and RecordType replace FunctionTest, ArrayTest, MapTest, and RecordTest, with no change in meaning.

  3. Parameter names may be included in a function signature; they are purely documentary.   [Issue 1136  PR 1696 12 January 2025]

A FunctionType matches selected function items, potentially checking their signatureDM (which includes the types of the arguments and results).

FunctionType::=Annotation* (AnyFunctionType
| TypedFunctionType)
Annotation::="%" EQName ("(" (AnnotationValue ++ ",") ")")?
AnyFunctionType::=("function" | "fn") "(" "*" ")"
TypedFunctionType::=("function" | "fn") "(" (TypedFunctionParam ** ",") ")" "as" SequenceType
TypedFunctionParam::=("$" EQName "as")? SequenceType
EQName::=QName | URIQualifiedName
SequenceType::=("empty-sequence" "(" ")")
| (ItemTypeOccurrenceIndicator?)

The keywords function and fn are synonyms.

If the contains an , then this is interpreted as a function assertion, as described below.

An AnyFunctionType matches any function item, including a map or an array. For example, the following expressions all return true:

  • fn:name#1 instance of function(*)

  • fn { @id } instance of function(*)

  • fn:random-number-generator() instance of function(*)

  • [ 1, 2, 3 ] instance of fn(*)

  • {} instance of fn(*)

A TypedFunctionType matches a function item if the function’s type signature (as defined in Section 7.1 Function ItemsDM) is a subtype of the TypedFunctionType.

Note:

The keywords function and fn are synonymous.

If parameter names are included in a TypedFunctionType, they are purely documentary and have no semantic effect. In particular, they play no part in deciding whether a particular function item matches the function type, and they never appear as keywords in function calls. For example the construct function($x as node()) as xs:string designates exactly the same type as function(node()) as xs:string.

Any parameter names that are supplied must be distinct [err:XQST0039].

A TypedFunctionType may also match certain maps and arrays, as described in 3.2.8.2 Map Types and 3.2.8.4 Array Types

Here are some examples of expressions that use a TypedFunctionType:

  • fn:count#1 instance of function(item()*) as xs:integer returns true, because the signature of the function item fn:count#1 is function(item()*) as xs:integer.

  • fn:count#1 instance of function(xs:string*) as item() returns true, because the signature of the function item fn:count#1 is a subtype of function(xs:string*) as item().

    Note:

    The same type might also be written fn($x as xs:int, $y as xs:int) as xs:int.

  • $F instance of %my:assertion function(*) is true if $F is a function that satisfies the implementation-defined function assertion %my:assertion.

  • $F instance of %my:assertion function(xs:int, xs:int) as xs:int is true if $F is a function item with the function signature function(xs:int, xs:int) as xs:int that satisfies the implementation-defined function assertion %my:assertion.

  • function(xs:anyAtomicType) as item()* matches any map, or any other function item with the required signature.

  • function(xs:integer) as item()* matches any array, or any other function item with the required signature.

[Definition: A function assertion is a predicate that restricts the set of functions matched by a FunctionType. It uses the same syntax as 5.15 Annotations.] XQuery 4.0 does not currently define any function assertions, but future versions may. Other specifications in the XQuery family may also use function assertions in the future.

An unprefixed QName used within a function assertion is taken to refer to the namespace http://www.w3.org/2012/xquery. Since this is a reserved namespace, and no assertions are currently defined in this namespace, this means that in practice, use of an unprefixed QName is always an error.

Implementations are free to define their own function assertions, whose behavior is completely implementation-defined. Implementations may also provide a way for users to define their own function assertions.

An implementation may raise implementation-defined errors or warnings for function assertions, for example if the parameters are not correct for a given assertion. If the namespace URI of a function assertion’s expanded QName is not recognized by an implementation, it is ignored, and has no effect on the semantics of the function type.

Note:

An implementation is free to raise warnings for function assertions that it does not recognize.

Note:

Although function assertions use the same syntax as annotations, they are not directly related to annotations. If an implementation defines the annotation blue and uses it in function declarations, there is no guarantee that it will also define a function assertion blue, or that a function assertion named blue matches a function declared with the annotation blue. Of course, an implementation that does so may be more intuitive to users.

Implementations must not define function assertions in reserved namespaces; it is is a static error [err:XQST0045] for a user to define a function assertion in a reserved namespace.

3.2.8.3 Record Types

Changes in 4.0 ⬇ ⬆

  1. Record types are added as a new kind of ItemType, constraining the value space of maps.

  2. The syntax record(*) is allowed; it matches any map.   [Issue 52 PR 728 10 October 2023]

  3. The syntax record() is allowed; the only thing it matches is an empty map.   [Issue 1491 PR 1577 17 October 2024]

A RecordType matches maps that meet specific criteria.

For example, the RecordTyperecord(r as xs:double, i as xs:double) matches a map if the map has exactly two entries: an entry with key "r" whose value is a singletonxs:double value, and an entry with key "i" whose value is also a singletonxs:double value.

Record types describe a subset of the value space of maps. They do not define any new kinds of values, or any additional operations. They are useful in many cases to describe more accurately the type of a variable, function parameter, or function result, giving benefits both in the readability of the code, and in the ability of the processor to detect and diagnose type errors and to optimize execution.

RecordType::=AnyRecordType | TypedRecordType
AnyRecordType::="record" "(" "*" ")"
TypedRecordType::="record" "(" (FieldDeclaration ** ",") ExtensibleFlag? ")"
FieldDeclaration::=FieldName "?"? ("as" SequenceType)?
FieldName::=NCName | StringLiteral
StringLiteral::=AposStringLiteral | QuotStringLiteral
/* ws: explicit */
SequenceType::=("empty-sequence" "(" ")")
| (ItemTypeOccurrenceIndicator?)
ExtensibleFlag::="," "*"

If the list of fields ends with ",*" then the record type is said to be extensible. For example, the RecordTyperecord(e as element(Employee), *) matches a map if it has an entry with key "e" whose value matches element(Employee), regardless what other entries the map might contain.

For generality:

  • The syntax record() defines a record type that has no explicit fields and that is not extensible. The only thing it matches is an empty mapDM.

  • The syntax record(*) defines an extensible record type that has no explicit field declarations. It is equivalent to the item type map(*): that is, it matches any map.

A record type can constrain only those entries whose keys are strings, but when the record type is marked as extensible, then other entries may be present in the map with either string or non-string keys. Entries whose key is a string can be expressed using an (unquoted) NCName if the key conforms to NCName syntax, or using a (quoted) string literal otherwise.

Although constructors for named record types produce a map in which the entry orderDM reflects the order of field definitions in the record type definition, the entry orderDM of a map has no effect on whether the map matches a particular record type: the entries in a map do not have to be in any particular order.

Note:

Lookup expressions have been extended in 4.0 so that non-NCName keys can be used without parentheses: employee?"middle name"

If the type declaration for a field is omitted, then item()* is assumed: that is, the map entry may have any type.

If the field name is followed by a question mark, then the value must have the specified type if it is present, but it may also be absent. For example, the RecordTyperecord(first as xs:string, middle? as xs:string, last as xs:string, *) requires the map to have string-valued entries with keys "first" and "last"; it also declares that if the map has an entry with key "middle", the value of that entry must be a single xs:string. Declaring the type as record(first as xs:string, middle? as xs:string?, last as xs:string, *) also allows the entry with key "middle" to be present but empty.

Note:

Within an extensible record type, a FieldDeclaration that is marked optional and has no declared type does not constrain the map in any way, so it serves no practical purpose, but it is permitted because it may have documentary value.

The names of the fields in a record type must be distinct [err:XPST0021].

If a variable $rec is known to conform to a particular record type, then when a lookup expression $rec?field is used, (a) the processor can report a type error if $rec cannot contain an entry with name field (see 4.14.3.4 Implausible Lookup Expressions), and (b) the processor can make static type inferences about the type of value returned by $rec?field.

Note:

(TODO: change function signatures as suggested here!) A number of functions in the standard function library use maps as function arguments; this is a useful technique where the information to be supplied across the interface is highly variable. However, the type signature for such functions typically declares the argument type as map(*), which gives very little information (and places very few constraints) on the values that are actually passed across. Using record types offers the possibility of improving this: for example, the options argument of fn:parse-json, previously given as map(*), can now be expressed as record(liberal? as xs:boolean, duplicates? as xs:string, escape? as xs:boolean, fallback as fn(xs:string) as xs:string, *). In principle the xs:string type used to describe the duplicates option could also be replaced by a schema-defined subtype of xs:string that enumerates the permitted values ("reject", "use-first", "use-last").

The use of a record type in the signature of such a function causes the coercion rules to be invoked. So, for example, if the function expects an entry in the map to be an xs:double value, it becomes possible to supply a map in which the corresponding entry has type xs:integer.

Greater precision in defining the types of such arguments also enables better type checking, better diagnostics, better optimization, better documentation, and better syntax-directed editing tools.

Note:

One of the motivations for introducing record types is to enable better pattern matching in XSLT when processing JSON input. With XML input, patterns are often based around XML element names. JSON has no direct equivalent of XML’s element names; matching a JSON object such as {longitude: 130.2, latitude: 53.4} relies instead on recognizing the property names appearing in the object. XSLT 4.0, by integrating record types into pattern matching syntax, allows such an object to be matched with a pattern of the form match="record(longitude, latitude)"

Rules defining whether one record type is a subtype of another are given in 3.3.2.8 Subtyping Records.

3.3 Subtype Relationships

Changes in 4.0 ⬇ ⬆

  1. 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.  [Issue 196 PR 202 25 October 2022]

[Definition: Given two sequence types or item types, the rules in this section determine if one is a subtype of the other. If a type A is a subtype of type B, it follows that every value matched by A is also matched by B.]

Note:

The relationship subtype(A, A) is always true: every type is a subtype of itself.

Note:

The converse is not necessarily true: we cannot infer that if every value matched by A is also matched by B, then A is a subtype of type B. For example, A might be defined as the set of strings matching the regular expression [A-Z]*, while B is the set of strings matching the regular expression [A-Za-z]*; no subtype relationship holds between these types.

The rules for deciding whether one sequence type is a subtype of another are given in 3.3.1 Subtypes of Sequence Types. The rules for deciding whether one item type is a subtype of another are given in 3.3.2 Subtypes of Item Types.

Note:

The subtype relationship is not acyclic. There are cases where subtype(A, B) and subtype(B, A) are both true. This implies that A and B have the same value space, but they can still be different types. For example this applies when A is a union type with member types xs:string and xs:integer, while B is a union type with member types xs:integer and xs:string. These are different types ("23" cast as A produces a string, while "23" cast as B produces an integer, because casting is attempted to each member type in order) but both types have the same value space.

3.3.2 Subtypes of Item Types

We use the notation A ⊆ B, or itemtype-subtype(A, B) to indicate that an item typeA is a subtype of an item type B. This section defines the rules for deciding whether any two item types have this relationship.

The rules in this section apply to item types, not to item type designators. For example, if the name STR has been defined in the static context as a named item type referring to the type xs:string, then anything said here about the type xs:string applies equally whether it is designated as xs:string or as STR, or indeed as the parenthesized forms (xs:string) or (STR).

References to named item types are handled as described in 3.3.2.9 Subtyping of Named Item Types.

The relationship A ⊆ B is true if and only if at least one of the conditions listed in the following subsections applies:

3.3.2.4 Subtyping of Node Types

The following subsections describe the subtype relationships among node types.

3.3.2.4.2 Subtyping Nodes: Document Nodes

Changes in 4.0 ⬇ ⬆

  1. The rules for subtyping of document node types have been refined.  [Issue 1624 PR 1898 7 April 2025]

Given item types A and B, A ⊆ B is true if any of the following rules apply.

These rules apply after expanding document-node(N), where N is a NameTestUnion, to the equivalent document-node(element(N)).

  1. A is document-node(E) for any E, and B is document-node().

    Examples:

    document-node(element(chap)) ⊆ document-node()

    document-node(*) ⊆ document-node()

  2. All the following are true:

    1. A is document-node(Ae)

    2. B is document-node(Be)

    3. Ae ⊆ Be

    Examples:

    document-node(element(title)) ⊆ document-node(element(*)).

    document-node(title) ⊆ document-node(*).

  3. A is document-node(element(A1|A2|..., T)) (where T may be absent), and for each An, document-node(element(An, T)) ⊆ B.

    Examples:

    • document-node(a|b) ⊆ document-node(a) | document-node(b)

    • document-node(a|b) ⊆ document-node(a|b|c)

3.4 Coercion Rules

Changes in 4.0 ⬇ ⬆

  1. The term "function conversion rules" used in 3.1 has been replaced by the term "coercion rules".   [ PR 254 29 November 2022]

  2. 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.   [Issue 117 PR 254 29 November 2022]

  3. 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.   [Issue 980 PR 911 30 January 2024]

  4. The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.   [Issues 130 480 PR 815 7 November 2023]

  5. The coercion rules now apply recursively to the members of an array and the entries in a map.   [Issue 1318 PR 1501 29 October 2024]

  6. The coercion rules now reorder the entries in a map when the required type is a record type.   [Issue 1862 PR 1874 25 March 2025]

[Definition: The coercion rules are rules used to convert a supplied value to a required type, for example when converting an argument of a function call to the declared type of the function parameter. ] The required type is expressed as a sequence type. The effect of the coercion rules may be to accept the value as supplied, to convert it to a value that matches the required type, or to reject it with a type error.

This section defines how the coercion rules operate; the situations in which the rules apply are defined elsewhere, by reference to this section.

Note:

In previous versions of this specification, the coercion rules were referred to as the function conversion rules. The terminology has changed because the rules are not exclusively associated with functions or function calling.

If the required type is empty-sequence(), no coercion takes place (the supplied value must be an empty sequence, or a type error occurs).

In all other cases, the required sequence typeT comprises a required item typeR and an optional occurrence indicator. The coercion rules are then applied to a supplied value V and the required type T as follows:

  1. Each item in V is processed against the required item type R using the item coercion rules defined in 3.4.1 Item Coercion Rules, and the results are sequence-concatenated into a single sequence V′.

  2. A type error is raised if the cardinality of V′ does not match the required cardinality of T [err:XPTY0004].

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.6 Path Expressions

PathExpr::=("/" RelativePathExpr?)
| ("//" RelativePathExpr)
| RelativePathExpr
/* xgc: leading-lone-slash */
RelativePathExpr::=StepExpr (("/" | "//") StepExpr)*

[Definition: A path expression consists of a series of one or more steps, separated by / or //, and optionally beginning with / or //. A path expression is typically used to locate nodes within trees. ]

Absolute path expressions (those starting with an initial / or //), start their selection from the root node of a tree; relative path expressions (those without a leading / or //) start from the context value.

A path expression consisting of a single step is evaluated as described in 4.6.4 Steps.

4.6.4 Steps

StepExpr::=PostfixExpr | AxisStep
PostfixExpr::=PrimaryExpr | FilterExpr | DynamicFunctionCall | LookupExpr | FilterExprAM
AxisStep::=(ReverseStep | ForwardStep) Predicate*

[Definition: A step is a part of a path expression that generates a sequence of items and then filters the sequence by zero or more predicates. The value of the step consists of those items that satisfy the predicates, working from left to right. A step may be either an axis step or a postfix expression.] Postfix expressions are described in 4.3 Postfix Expressions.

[Definition: An axis step returns a sequence of nodes that are reachable from a starting node via a specified axis. Such a step has two parts: an axis, which defines the "direction of movement" for the step, and a node test, which selects nodes based on their kind, name, and/or type annotation .]

If the context value is a sequence of zero or more nodes, an axis step returns a sequence of zero or more nodes; otherwise, a type error is raised [err:XPTY0020].

The step expression S is equivalent to ./S. Thus, if the context value is a sequence containing multiple nodes, the semantics of a step expression are equivalent to a path expression in which the step is always applied to a single node. The following description therefore explains the semantics for the case where the context value is a single node, called the context node.

Note:

The equivalence of a step S to the path expression ./S means that the resulting node sequence is returned in document order.

An axis step may be either a forward step or a reverse step, followed by zero or more predicates.

In the abbreviated syntax for a step, the axis can be omitted and other shorthand notations can be used as described in 4.6.7 Abbreviated Syntax.

The unabbreviated syntax for an axis step consists of the axis name and node test separated by a double colon. The result of the step consists of the nodes reachable from the starting node via the specified axis that have the node kind, name, and/or type annotation specified by the node test. For example, the step child::para selects the para element children of the context node: child is the name of the axis, and para is the name of the element nodes to be selected on this axis. The available axes are described in 4.6.4.1 Axes. The available node tests are described in 4.6.4.2 Node Tests. Examples of steps are provided in 4.6.6 Unabbreviated Syntax and 4.6.7 Abbreviated Syntax.

4.6.4.1 Axes

Changes in 4.0 ⬇ ⬆

  1. Four new axes have been defined: preceding-or-self, preceding-sibling-or-self, following-or-self, and following-sibling-or-self.   [Issue 1519 PR 1532 29 October 2024]

ForwardAxis::=("attribute"
| "child"
| "descendant"
| "descendant-or-self"
| "following"
| "following-or-self"
| "following-sibling"
| "following-sibling-or-self"
| "self") "::"
ReverseAxis::=("ancestor"
| "ancestor-or-self"
| "parent"
| "preceding"
| "preceding-or-self"
| "preceding-sibling"
| "preceding-sibling-or-self") "::"

XQuery supports the following axes:

  • The child axis contains the children of the context node, which are the nodes returned by the Section 6.7.3 children AccessorDM.

    Note:

    Only document nodes and element nodes have children. If the context node is any other kind of node, or if the context node is an empty document or element node, then the child axis is an empty sequence. The children of a document node or element node may be element, processing instruction, comment, or text nodes. Attribute and document nodes can never appear as children.

  • The descendant axis is defined as the transitive closure of the child axis; it contains the descendants of the context node (the children, the children of the children, and so on).

    More formally, $node/descendant::node() delivers the result of fn:transitive-closure($node, fn { child::node() }).

  • The descendant-or-self axis contains the context node and the descendants of the context node.

    More formally, $node/descendant-or-self::node() delivers the result of $node/(. | descendant::node()).

  • The parent axis contains the sequence returned by the Section 6.7.11 parent AccessorDM, which returns the parent of the context node, or an empty sequence if the context node has no parent.

    Note:

    An attribute node may have an element node as its parent, even though the attribute node is not a child of the element node.

  • The ancestor axis is defined as the transitive closure of the parent axis; it contains the ancestors of the context node (the parent, the parent of the parent, and so on).

    More formally, $node/ancestor::node() delivers the result of fn:transitive-closure($node, fn { parent::node() }).

    Note:

    The ancestor axis includes the root node of the tree in which the context node is found, unless the context node is the root node.

  • The ancestor-or-self axis contains the context node and the ancestors of the context node; thus, the ancestor-or-self axis will always include the root node.

    More formally, $node/ancestor-or-self::node() delivers the result of $node/(. | ancestor::node()).

  • The following-sibling axis contains the context node’s following siblings, that is, those children of the context node’s parent that occur after the context node in document order. If the context node is an attribute or namespace node, the following-sibling axis is empty.

    More formally, $node/following-sibling::node() delivers the result of fn:siblings($node)[. >> $node]).

  • The following-sibling-or-self axis contains the context node, together with the contents of the following-sibling axis.

    More formally, $node/following-sibling-or-self::node() delivers the result of fn:siblings($node)[not(. << $node)]

  • The preceding-sibling axis contains the context node’s preceding siblings, that is, those children of the context node’s parent that occur before the context node in document order. If the context node is an attribute or namespace node, the preceding-sibling axis is empty.

    More formally, $node/preceding-sibling::node() delivers the result of fn:siblings($node)[. << $node].

  • The preceding-sibling-or-self axis contains the context node, together with the contents of the preceding-sibling axis.

    More formally, $node/preceding-sibling-or-self::node() delivers the result of fn:siblings($node)[not(. >> $node).

  • The following axis contains all nodes that are descendants of the root of the tree in which the context node is found, are not descendants of the context node, and occur after the context node in document order.

    More formally, $node/following::node() delivers the result of $node/ancestor-or-self::node()/following-sibling::node()/descendant-or-self::node()

  • The following-or-self axis contains the context node, together with the contents of the following axis.

    More formally, $node/following-or-self::node() delivers the result of $node/(. | following::node()).

  • The preceding axis contains all nodes that are descendants of the root of the tree in which the context node is found, are not ancestors of the context node, and occur before the context node in document order.

    More formally, $node/preceding::node() delivers the result of $node/ancestor-or-self::node()/preceding-sibling::node()/descendant-or-self::node().

  • The preceding-or-self axis contains the context node, together with the contents of the preceding axis.

    More formally, $node/preceding-or-self::node() delivers the result of $node/(. | preceding::node()).

  • The attribute axis contains the attributes of the context node, which are the nodes returned by the Section 6.7.1 attributes AccessorDM; the axis will be empty unless the context node is an element.

  • The self axis contains just the context node itself.

    The self axis is primarily useful when testing whether the context node satisfies particular conditions, for example if ($x[self::chapter]).

    More formally, $node/self::node() delivers the result of $node.

Axes can be categorized as forward axes and reverse axes. An axis that only ever contains the context node or nodes that are after the context node in document order is a forward axis. An axis that only ever contains the context node or nodes that are before the context node in document order is a reverse axis.

The parent, ancestor, ancestor-or-self, preceding, preceding-or-self, preceding-sibling, and preceding-sibling-or-self axes are reverse axes; all other axes are forward axes.

The ancestor, descendant, following, preceding and self axes partition a document (ignoring attribute nodes): they do not overlap and together they contain all the nodes in the document.

[Definition: Every axis has a principal node kind. If an axis can contain elements, then the principal node kind is element; otherwise, it is the kind of nodes that the axis can contain.] Thus:

  • For the attribute axis, the principal node kind is attribute.

  • For all other axes, the principal node kind is element.

4.14 Maps and Arrays

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.

4.14.4 Filter Expressions for Maps and Arrays

Changes in 4.0 ⬇ ⬆

  1. Filter expressions for maps and arrays are introduced.   [Issue 1159 PR 1163 20 April 2024]

  2. Predicates in filter expressions for maps and arrays can now be numeric.   [Issue 1207 PR tba1217 15 May 2024]

FilterExprAM::=PostfixExpr "?[" Expr "]"
PostfixExpr::=PrimaryExpr | FilterExpr | DynamicFunctionCall | LookupExpr | FilterExprAM
Expr::=(ExprSingle ++ ",")

Maps and arrays can be filtered using the construct INPUT?[FILTER]. For example, $array?[count(.)=1] filters an array to retain only those members that are single items.

Note:

The character-pair ?[ forms a single token; no intervening whitespace or comment is allowed.

The required type of the left-hand operand INPUT is (map(*)|array(*))?: that is, it must be either an empty sequence, a single map, or a single array [err:XPTY0004]. If it is an empty sequence, the result of the expression is an empty sequence.

If the value of INPUT is an array, then the FILTER expression is evaluated for each member of the array, with that member as the context value, with its position in the array as the context position, and with the size of the array as the context size. The result of the expression is an array containing those members of the input array for which the predicate truth value of the FILTER expression is true. The order of retained members is preserved.

For example, the following expression:

let $array := [ (), 1, (2, 3), (4, 5, 6) ]
return $array?[count(.) ge 2]

returns:

[ (2, 3), (4, 5, 6) ]

Note:

Numeric predicates are handled in the same way as with filter expressions for sequences. However, the result is always an array, even if only one member is selected. For example, given the $array shown above, the result of $array?[3] is the single-member arrayDM[ (2, 3) ]. Contrast this with $array?3 which delivers the sequence 2, 3.

If the value of INPUT is a map, then the FILTER expression is evaluated for each entry in the map, with the context value set to an item of type record(key as xs:anyAtomicType, value as item()*), in which the key and value fields represent the key and value of the map entry. The context position is the position of the entry in the map (in entry orderDM), and the context size is the number of entries in the map. The result of the expression is a map containing those entries of the input map for which the predicate truth value of the FILTER expression is true. The relative order of entries in the result retains the relative order of entries in the input.

For example, the following expression:

let map := { 1: "alpha", 2: "beta", 3: "gamma" }
return $map?[?key ge 2]

returns:

{ 2: "beta", 3: "gamma" }

Note:

A filter expression such as $map?[last()-1, last()] might be used to return the last two entries of a map in entry orderDM.

4.15 Ordered and Unordered Expressions

Changes in 4.0 ⬇ ⬆

  1. 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.   [Issue 1339 PR 1342 3 September 2024]

OrderedExpr::="ordered" EnclosedExpr
EnclosedExpr::="{" Expr? "}"

This syntax is retained from earlier versions of XQuery; in XQuery 4.0 it is deprecated and has no effect.

The constructs ordered { E } and unordered { E } both return the result of evaluating the expression E.

Note:

In addition to ordered and unordered expressions, XQuery provides a function named fn:unordered that operates on any sequence of items and returns the same sequence in an implementation-defined order. A call to the fn:unordered function may be thought of as giving permission for the argument expression to be materialized in whatever order the system finds most efficient. The fn:unordered function relaxes ordering only for the sequence that is its immediate operand, whereas the unordered expression in earlier XQuery versions sets the ordering mode for its operand expression and all nested expressions.

4.20 Try/Catch Expressions

Changes in 4.0 ⬇ ⬆

  1. A new variable $err:map is available, capturing all error information in one place.   [Issue 32 PR 493 16 May 2023]

  2. $err:stack-trace provides information about the current state of execution.   [Issue 689  PR 1470 1 October 2024]

  3. A finally clause can be supplied, which will always be evaluated after the expressions of the try/catch clauses.   [Issue 501  PR 1914 4 April 2025]

The try/catch expression provides error handling for dynamic errors and type errors raised during dynamic evaluation, including errors raised by the XQuery implementation and errors explicitly raised in a query using the fn:error() function.

TryCatchExpr::=TryClause ((CatchClause+ FinallyClause?) | FinallyClause)
TryClause::="try" EnclosedExpr
EnclosedExpr::="{" Expr? "}"
CatchClause::="catch" NameTestUnionEnclosedExpr
NameTestUnion::=(NameTest ++ "|")
NameTest::=EQName | Wildcard
EQName::=QName | URIQualifiedName
Wildcard::="*"
| (NCName ":*")
| ("*:" NCName)
| (BracedURILiteral "*")
/* ws: explicit */
FinallyClause::="finally" EnclosedExpr

A try/catch expression catches dynamic errors and type errors raised by the evaluation of the target expression of the try clause. If the content expression of the try clause does not raise a dynamic error or a type error, the result of the try/catch expression is the result of the content expression.

If the target expression raises a dynamic error or a type error, the result of the try/catch expression is obtained by evaluating the first catch clause that “matches” the error value, as described below. If no catch clause “matches” the error value, then the try/catch expression raises the error that was raised by the target expression. A catch clause with one or more NameTests matches any error whose error code matches one of these NameTests. For instance, if the error code is err:FOER0000, then it matches a catch clause whose ErrorList is err:FOER0000 | err:FOER0001. Wildcards may be used in NameTests; thus, the error code err:FOER0000 also matches a catch clause whose ErrorList is err:* or *:FOER0000 or *.

Within the scope of the catch clause, a number of variables are implicitly declared, giving information about the error that occurred. These variables are initialized as described in the following table:

VariableTypeValue
$err:codexs:QNameThe error code
$err:descriptionxs:string?A description of the error condition; an empty sequence if no description is available (for example, if the error function was called with one argument).
$err:valueitem()*Value associated with the error. For an error raised by calling the error function, this is the value of the third argument (if supplied).
$err:modulexs:string?The URI (or system ID) of the module containing the expression where the error occurred, or an empty sequence if the information is not available.
$err:line-numberxs:integer?The line number within the module where the error occurred, or an empty sequence if the information is not available. The value may be approximate.
$err:column-numberxs:integer?The column number within the module where the error occurred, or an empty sequence if the information is not available. The value may be approximate.
$err:stack-tracexs:string?Implementation-dependent information about the current state of execution, or an empty sequence if no stack trace is available. The variable must be bound so that a query can reference it without raising an error.
$err:additionalitem()*Implementation-defined. Allows implementations to provide any additional information that might be useful. The variable must be bound so that a query can reference it without raising an error.
$err:mapmap(*)A map with entries for all values that are bound to the variables above. The local names of the variables are assigned as keys. No map entries are created for those values that are empty sequences. The variable can be used to pass on all error information to another function.

Try/catch expressions have a special rule for propagating dynamic errors. The try/catch expression ignores any dynamic errors encountered in catch clauses other than the first catch clause that matches an error raised by the try clause, and these catch clause expressions need not be evaluated.

Static errors are not caught by the try/catch expression.

If a function call occurs within a try clause, errors raised by evaluating the corresponding function are caught by the try/catch expression. If a variable reference is used in a try clause, errors raised by binding a value to the variable are not caught unless the binding expression occurs within the try clause.

Note:

The presence of a try/catch expression does not prevent an implementation from using a lazy evaluation strategy, nor does it prevent an optimizer performing expression rewrites. However, if the evaluation of an expression inside a try/catch is rewritten or deferred in this way, it must take its try/catch context with it. Similarly, expressions that were written outside the try/catch expression may be evaluated inside the try/catch, but only if they retain their original try/catch behavior. The presence of a try/catch does not change the rules that allow the processor to evaluate expressions in such a way that may avoid the detection of some errors.

If a concluding finally clause exists, its expression will be evaluated after the expressions of the try clause and a possibly evaluated catch clause. If it raises an error, this error is returned instead of a result or an error that resulted from a try or catch expression. If it raises no error, it must yield an empty sequence; otherwise, a dynamic error is raised [err:XQDY0153].

Note:

A finally clause can be used to ensure that an expression will always be evaluated, no matter if the try expression is successful or if it fails. For example, fn:message can be called in the finally clause to ensure that an expression has been evaluated even if an error is raised.

Note:

If try and finally clauses are specified, catch clauses can be omitted.

Here are some examples of try/catch expressions.

  • A try/catch expression without name tests catches any error:

    try {
  $x cast as xs:integer
} catch * {
  0
}

  • With the following catch clause, only err:FORG0001 is caught:

    try {
  $x cast as xs:integer
} catch err:FORG0001 {
  0
}

  • This try/catch expression specifies that errors err:FORG0001 and err:XPTY0004 are caught:

    try {
  $x cast as xs:integer
} catch err:FORG0001 | err:XPTY0004 {
  0
}

    Note:

    In some implementations, err:XPTY0004 is detected during static evaluation; it can only be caught if it is raised during dynamic evaluation.

  • This try/catch expression shows how to return information about the error using implicitly defined error variables:

    try {
  error(QName('http://www.w3.org/2005/xqt-errors', 'err:FOER0000'))
} catch * {
  $err:code, $err:value, " module: ",
  $err:module, "(", $err:line-number, ",", $err:column-number, ")"
}

  • Errors raised by using the result of a try/catch expression are not caught, since they are outside the scope of the try expression.

    declare function local:thrice($x as xs:integer) as xs:integer {
  3 * $x
};

local:thrice(try { "oops" } catch * { 3 } )

    In this example, the try block succeeds, returning the string "oops", which is not a valid argument to the function.

  • All available information about the error is serialized:

    try {
  1 + <empty/>
} catch * {
  serialize($err:map, { 'method': 'adaptive' })
}

  • fn:message will always be called, no matter if the division succeeds:

    for $i in 0 to 2
return try {
  1 div $i
} catch err:FOAR0001 {
  'division error'
} finally {
  message('1 was divided by ' || $i)
}

4.24 Arrow Expressions

Changes in 4.0 ⬇ ⬆

  1. 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.  [Issues 1716 1829 PRs 1763 1830 25 February 2025]

Arrow expressions apply a function to a value, using the value of the left-hand expression as the first argument to the function.

ArrowExpr::=UnaryExpr (SequenceArrowTarget | MappingArrowTarget)*
UnaryExpr::=("-" | "+")* ValueExpr
SequenceArrowTarget::="=>" ArrowTarget
ArrowTarget::=FunctionCall | RestrictedDynamicCall
FunctionCall::=EQNameArgumentList
/* xgc: reserved-function-names */
/* gn: parens */
RestrictedDynamicCall::=(VarRef | ParenthesizedExpr | FunctionItemExpr | MapConstructor | ArrayConstructor) PositionalArgumentList
VarRef::="$" EQName
ParenthesizedExpr::="(" Expr? ")"
FunctionItemExpr::=NamedFunctionRef | InlineFunctionExpr
NamedFunctionRef::=EQName "#" IntegerLiteral
/* xgc: reserved-function-names */
InlineFunctionExpr::=Annotation* ("function" | "fn") FunctionSignature? FunctionBody
MapConstructor::="map"? "{" (MapConstructorEntry ** ",") "}"
ArrayConstructor::=SquareArrayConstructor | CurlyArrayConstructor
PositionalArgumentList::="(" PositionalArguments? ")"
PositionalArguments::=(Argument ++ ",")
MappingArrowTarget::="=!>" ArrowTarget

The arrow syntax is particularly helpful when applying multiple functions to a value in turn. For example, the following expression invites syntax errors due to misplaced parentheses: 

tokenize((normalize-unicode(upper-case($string))),"\s+")

In the following reformulation, it is easier to see that the parentheses are balanced:

$string => upper-case() => normalize-unicode() => tokenize("\s+")

When the operator is written as =!>, the function is applied to each item in the sequence in turn. Assuming that $string is a single string, the above example could equally be written:

$string =!> upper-case() =!> normalize-unicode() =!> tokenize("\s+")

The difference between the two operators is seen when the left-hand operand evaluates to a sequence:

(1, 2, 3) => avg()

returns a value of only one item, 2, the average of all three items, whereas 

(1, 2, 3) =!> avg()

returns the original sequence of three items, (1, 2, 3), each item being the average of itself. The following example:

"The cat sat on the mat"
=> tokenize()
=!> concat(".")
=!> upper-case()
=> string-join(" ")

returns "THE. CAT. SAT. ON. THE. MAT.". The first arrow could be written either as => or =!> because the operand is a singleton; the next two arrows have to be =!> because the function is applied to each item in the tokenized sequence individually; the final arrow must be => because the string-join function applies to the sequence as a whole.

Note:

It may be useful to think of this as a map/reduce pipeline. The functions introduced by =!> are mapping operations; the function introduced by => is a reduce operation.

The following example introduces an inline function to the pipeline:

(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn($a) { $a + 1 }() => sum()

This is equivalent to sum((1 to 5) ! (math:sqrt(xs:double(.)) + 1)).

The same effect can be achieved using a focus function:

(1 to 5) =!> xs:double() =!> math:sqrt() =!> fn { . + 1 }() => sum()

It could also be expressed using the mapping operator !:

(1 to 5) ! xs:double(.) ! math:sqrt(.) ! (. + 1) => sum()

Note:

The ArgumentList may include PlaceHolders, though this is not especially useful. For example, the expression "$" => concat(?) is equivalent to concat("$", ?): its value is a function that prepends a supplied string with a $ symbol.

Note:

The ArgumentList may include keyword arguments if the function is identified statically (that is, by name). For example, the following is valid: $xml => xml-to-json(indent := true()) => parse-json(escape := false()).

The sequence arrow operator thus applies the supplied function to the left-hand operand as a whole, while the mapping arrow operator applies the function to each item in the value of the left-hand operand individually. In the case where the result of the left-hand operand is a single item, the two operators have the same effect.

Note:

The mapping arrow symbol =!> is intended to suggest a combination of function application (=>) and sequence mapping (!) combined in a single operation.

The construct on the right-hand side of the arrow operator (=>) can either be a static function call, or a restricted form of dynamic function call. The restrictions are there to ensure that the two forms can be distinguished by the parser with limited lookahead. For a dynamic call, the function item to be called can be expressed as a variable reference, an inline function expression, a named function reference, a map constructor, or an array constructor. Any other expression used to return the required function item must be enclosed in parentheses.

5 Modules and Prologs

Module::=VersionDecl? (LibraryModule | MainModule)
VersionDecl::="xquery" (("encoding" StringLiteral) | ("version" StringLiteral ("encoding" StringLiteral)?)) Separator
LibraryModule::=ModuleDeclProlog
ModuleDecl::="module" "namespace" NCName "=" URILiteralSeparator
Prolog::=((DefaultNamespaceDecl | Setter | NamespaceDecl | Import) Separator)* ((ContextValueDecl | VarDecl | FunctionDecl | ItemTypeDecl | NamedRecordTypeDecl | OptionDecl) Separator)*
DefaultNamespaceDecl::="declare" "fixed"? "default" ("element" | "function") "namespace" URILiteral
Setter::=BoundarySpaceDecl | DefaultCollationDecl | BaseURIDecl | ConstructionDecl | OrderingModeDecl | EmptyOrderDecl | CopyNamespacesDecl | DecimalFormatDecl
BoundarySpaceDecl::="declare" "boundary-space" ("preserve" | "strip")
DefaultCollationDecl::="declare" "default" "collation" URILiteral
BaseURIDecl::="declare" "base-uri" URILiteral
ConstructionDecl::="declare" "construction" ("strip" | "preserve")
OrderingModeDecl::="declare" "ordering" ("ordered" | "unordered")
EmptyOrderDecl::="declare" "default" "order" "empty" ("greatest" | "least")
CopyNamespacesDecl::="declare" "copy-namespaces" PreserveMode "," InheritMode
DecimalFormatDecl::="declare" (("decimal-format" EQName) | ("default" "decimal-format")) (DFPropertyName "=" StringLiteral)*
NamespaceDecl::="declare" "namespace" NCName "=" URILiteral
Import::=SchemaImport | ModuleImport
SchemaImport::="import" "schema" SchemaPrefix? URILiteral ("at" (URILiteral ++ ","))?
ModuleImport::="import" "module" ("namespace" NCName "=")? URILiteral ("at" (URILiteral ++ ","))?
Separator::=";"
ContextValueDecl::="declare" "context" (("value" ("as" SequenceType)?) | ("item" ("as" ItemType)?)) ((":=" VarValue) | ("external" (":=" VarDefaultValue)?))
VarDecl::="declare" Annotation* "variable" VarNameAndType ((":=" VarValue) | ("external" (":=" VarDefaultValue)?))
FunctionDecl::="declare" Annotation* "function" EQName "(" ParamListWithDefaults? ")" TypeDeclaration? (FunctionBody | "external")
/* xgc: reserved-function-names */
ItemTypeDecl::="declare" Annotation* "type" EQName "as" ItemType
NamedRecordTypeDecl::="declare" Annotation* "record" EQName "(" (ExtendedFieldDeclaration ** ",") ExtensibleFlag? ")"
OptionDecl::="declare" "option" EQNameStringLiteral
MainModule::=PrologQueryBody
QueryBody::=Expr
Expr::=(ExprSingle ++ ",")

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.

5.7 Ordering Mode Declaration

Changes in 4.0 ⬇ ⬆

  1. The ordering mode declaration is retained for backwards compatibility reasons, but in XQuery 4.0 it is deprecated and has no useful effect.   [Issue 1339 PR 1342 3 September 2024]

OrderingModeDecl::="declare" "ordering" ("ordered" | "unordered")

The ordering mode declaration is retained from earlier XQuery versions, but in XQuery 4.0 it is deprecated and has no effect.

Note:

That is to say, XQuery 4.0 always operates as if ordering mode were set to ordered in earlier versions.

If a Prolog contains more than one ordering mode declaration, a static error is raised [err:XQST0065].

J Change Log (Non-Normative)

  1. Use the arrows to browse significant changes since the 3.1 version of this specification.

    See 1 Introduction

  2. Sections with significant changes are marked Δ in the table of contents.

    See 1 Introduction

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

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

  5. Record types are added as a new kind of ItemType, constraining the value space of maps.

    See 3.2.8.3 Record Types

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

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

  8. The symbols × and ÷ can be used for multiplication and division.

    See 4.8 Arithmetic Expressions

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

  10. Operators such as < and > can use the full-width forms ＜ and ＞ to avoid the need for XML escaping.

    See 4.10.2 General Comparisons

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

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

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

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

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

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

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

  18. $err:stack-trace provides information about the current state of execution.

    See 4.20 Try/Catch Expressions

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

  20. Parameter names may be included in a function signature; they are purely documentary.

    See 3.2.8.1 Function Types

  21. PR tba 

    Predicates in filter expressions for maps and arrays can now be numeric.

    See 4.14.4 Filter Expressions for Maps and Arrays

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

  23. The static typing feature has been dropped.

    See 6 Conformance

    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

  24. The syntax record() is allowed; the only thing it matches is an empty map.

    See 3.2.8.3 Record Types

  25. The context value static type, which was there purely to assist in static typing, has been dropped.

    See 2.2.1 Static Context

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

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

  28. The rules for subtyping of document node types have been refined.

    See 3.3.2.4.2 Subtyping Nodes: Document Nodes

  29. The coercion rules now reorder the entries in a map when the required type is a record type.

    See 3.4 Coercion Rules

  30. PR 159 

    Keyword arguments are allowed on static function calls, as well as positional arguments.

    See 4.5.1.1 Static Function Call Syntax

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

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

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

  34. PR 284 

    Alternative syntax for conditional expressions is available: if (condition) { X }.

    See 4.16 Conditional Expressions

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

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

  37. PR 326 

    Support for higher-order functions is now a mandatory feature (in 3.1 it was optional).

    See 6 Conformance

  38. PR 344 

    A for member clause is added to FLWOR expressions to allow iteration over an array.

    See 4.13.2 For Clause

  39. PR 364 

    Switch expressions now allow a case clause to match multiple atomic items.

    See 4.18 Switch Expressions

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

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

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

  43. PR 493 

    A new variable $err:map is available, capturing all error information in one place.

    See 4.20 Try/Catch Expressions

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

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

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

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

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

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

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

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

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

  53. PR 691 

    Enumeration types are added as a new kind of ItemType, constraining the value space of strings.

    See 3.2.6 Enumeration Types

  54. PR 728 

    The syntax record(*) is allowed; it matches any map.

    See 3.2.8.3 Record Types

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

  56. PR 815 

    The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.

    See 3.4 Coercion Rules

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

  58. PR 837 

    A deep lookup operator ?? is provided for searching trees of maps and arrays.

    See 4.14.3 Lookup Expressions

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

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

  61. PR 996 

    The value of a predicate in a filter expression can now be a sequence of integers.

    See 4.4 Filter Expressions

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

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

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

  65. PR 1132 

    Choice item types (an item type allowing a set of alternative item types) are introduced.

    See 3.2.5 Choice Item Types

  66. PR 1163 

    Filter expressions for maps and arrays are introduced.

    See 4.14.4 Filter Expressions for Maps and Arrays

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

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

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

  70. PR 1217 

    Predicates in filter expressions for maps and arrays can now be numeric.

    See 4.14.4 Filter Expressions for Maps and Arrays

  71. PR 1249 

    A for key/value clause is added to FLWOR expressions to allow iteration over a map.

    See 4.13.2 For Clause

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

  73. PR 1254 

    The rules concerning the interpretation of xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes have been tightened up.

    See 4.25 Validate Expressions

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

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

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

  77. PR 1361 

    The term atomic value has been replaced by atomic item.

    See 2.1.2 Values

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

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

  80. PR 1470 

    $err:stack-trace provides information about the current state of execution.

    See 4.20 Try/Catch Expressions

  81. PR 1480 

    When the element name matches a language keyword such as div or value, it must now be written in quotes as a string 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 in quotes as a string literal. This is a backwards incompatible change.

    See 4.12.3.2 Computed Attribute Constructors

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

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

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

  85. PR 1513 

    When the processing instruction name matches a language keyword such as try or validate, it must now be written in quotes as a string literal. 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 in quotes as a string literal. This is a backwards incompatible change.

    See 4.12.3.7 Computed Namespace Constructors

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

  87. PR 1577 

    The syntax record() is allowed; the only thing it matches is an empty map.

    See 3.2.8.3 Record Types

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

  89. PR 1696 

    Parameter names may be included in a function signature; they are purely documentary.

    See 3.2.8.1 Function Types

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

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

  92. PR 1898 

    The rules for subtyping of document node types have been refined.

    See 3.3.2.4.2 Subtyping Nodes: Document Nodes

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