XQuery 4.0: An XML Query Language

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:

atomic items in XQuery 4.0 (which are one kind of item) have atomic types such as xs:string, xs:boolean, and xs:integer. These types are taken directly from their definitions in [XML Schema 1.0] or [XML Schema 1.1].
Nodes (which are another kind of item) have a property called a type annotation which determines the type of their content. The type annotation is a schema type. The type annotation of a node must not be confused with the item type of the node. For example, an element <age>23</age> might have been validated against a schema that defines this element as having xs:integer content. If this is the case, the type annotation of the node will be xs:integer, and in the XQuery 4.0 type system, the node will match the item typeelement(age, xs:integer).

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

Changes in 4.0 ⬇ ⬆

The term "function conversion rules" used in 3.1 has been replaced by the term "coercion rules". [ PR 254 29 November 2022]
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]
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]
The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary. [Issues 130 480 PR 815 7 November 2023]
The coercion rules now apply recursively to the members of an array and the entries in a map. [Issue 1318 PR 1501]
The coercion rules now apply recursively to the members of an array and the entries in a map. [Issue 1318 PR 1501]
The coercion rules now reorder the entries in a map when the required type is a record type. [Issue 1862 ]
The coercion rules now reorder the entries in a map when the required type is a record type. [Issue 1862 ]

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

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′.
A type error is raised if the cardinality of V′ does not match the required cardinality of T [err:XPTY0004].

3.4.1 Item Coercion Rules

The rules in this section are used to process each item J in a supplied sequence, given a required item typeR.

If R is a generalized atomic type (for example, if it is an atomic type, a pure union type, or an enumeration type), and J is not an atomic item, then:
1. J is atomized to produce a sequence of atomic items JJ.
2. Each atomic item in JJ is coerced to the required type R by recursive application of the item coercion rules (the rules in this section) to produce a value V.
3. The result is the sequence-concatenation of the V values.
Note:
For example, if J is an element with type annotation xs:integer, and R is the union type xs:numeric, then the effect is to atomize the element to an xs:integer, and then to coerce the resulting xs:integer to xs:numeric (which leaves the integer unchanged). This is not the same as attempting to coerce the element to each of the alternatives of the union type in turn, which would deliver an instance of xs:double.
Otherwise, if R is a choice item type or a pure union type (which includes the case where it is an enumeration type), then:
1. If J matches (is an instance of) one of the alternatives in R, then J is coerced to the first alternative in R that J: matches.
  1. If the first alternative in R that J matches is a typed function type (see 3.2.8.1 Function Types), then function coercion is applied to coerce J to that function type, as described in 3.4.3 Function Coercion.
  2. Otherwise, J is used as is.
  Note:
  There are two situations where coercing an item to a type that it already matches does not simply return the item unchanged:
  - When the required type is a typed function type (see 3.2.8.1 Function Types), then function coercion is applied to coerce J to that function type, as described in 3.4.3 Function Coercion.
  - When the required type is a record type and the supplied value is a map, then coercion may change the entry order^DM of the entries in the map.
2. Otherwise, the item coercion rules (the rules in this section) are applied to J recursively with R set to each of the alternatives in the choice or union item type, in order, until an alternative is found that does not result in a type error; a type error is raised only if all alternatives fail.
  The error code used in the event of failure should be the error code arising from the first unsuccessful matching attempt. (The diagnostic information associated with the error may also describe how further attempts failed.)
Note:
Suppose the required type is (xs:integer | element(e))* and the supplied value is the sequence (<e>22</e>, 23, <f>24</f>). Item coercion is applied independently to each of the three items in this sequence. The first item matches one of the alternatives, namely element(e), so it is returned unchanged as an element node. The second item (the integer 23) also matches one of the alternatives, and is returned unchanged as an integer. The third item does not match any of the alternatives, so coercion is attempted to each one in turn. Coercion to type xs:integer succeeds (by virtue of atomization and untyped atomic conversion), so the final result is the sequence (<e>22</e>, 23, 24)
Note:
Suppose the required type is enum("red", "green", "blue") and the supplied value is "green". The enumeration type is defined as a choice item type whose alternatives are singleton enumerations, so the rules are applied first to the type enum("red") (which fails), and then to the type enum("green") (which succeeds). The strings in an enumeration type are required to be distinct so the order of checking is in this case immaterial. The supplied value will be accepted, and will be relabeled as an instance of enum("green"), which is treated as a schema type equivalent to a type derived from xs:string by restriction.
Note:
Schema-defined union types behave in exactly the same way as choice item types.
If R is an atomic type and J is an atomic item, then:
1. If J is an instance of R then it is used unchanged.
2. If J is an instance of type xs:untypedAtomic then:
  1. If R is an enumeration type then A is cast to xs:string.
  2. If R is namespace-sensitive then a type error [err:XPTY0117] is raised.
3. Otherwise, J is cast to type R.

If there is an entry (from, to) in the following table such that J is an instance of from, and to is R, then J is cast to type R.

Implicit Casting
from	to
`xs:decimal`	`xs:double`
`xs:double`	`xs:decimal`
`xs:decimal`	`xs:float`
`xs:float`	`xs:decimal`
`xs:float`	`xs:double`
`xs:double`	`xs:float`
`xs:string`	`xs:anyURI`
`xs:anyURI`	`xs:string`
`xs:hexBinary`	`xs:base64Binary`
`xs:base64Binary`	`xs:hexBinary`

Note:

The item type in the to column must match R exactly; however, J may belong to a subtype of the type in the from column.

For example, an xs:NCName will be cast to type xs:anyURI, but an xs:anyURI will not be cast to type xs:NCName.

Similarly, an xs:integer will be cast to type xs:double, but an xs:double will not be cast to type xs:integer.

If R is derived from some primitive atomic type P, then J is relabeled as an instance of R if it satisfies all the following conditions:
- J is an instance of P.
- J is not an instance of R.
- The datum^DM of J is within the value space of R.
Relabeling an atomic item changes the type annotation but not the datum^DM. For example, the xs:integer value 3 can be relabeled as an instance of xs:unsignedByte, because the datum is within the value space of xs:unsignedByte.
Note:
Relabeling is not the same as casting. For example, the xs:decimal value 10.1 can be cast to xs:integer, but it cannot be relabeled as xs:integer, because its datum not within the value space of xs:integer.
Note:
The effect of this rule is that if, for example, a function parameter is declared with an expected type of xs:positiveInteger, then a call that supplies the literal value 3 will succeed, whereas a call that supplies -3 will fail.
This differs from previous versions of this specification, where both these calls would fail.
This change allows the arguments of existing functions to be defined with a more precise type. For example, the $position argument of array:get could be defined as xs:positiveInteger rather than xs:integer.
Note:
If T is a union type with members xs:negativeInteger and xs:positiveInteger)* and the supplied value is the sequence (20, -20), then the effect of these rules is that the first item 20 is relabeled as type xs:positiveInteger and the second item -20is relabeled as type xs:negativeInteger.
Note:
Promotion (for example of xs:float to xs:double) occurs only when T is a primitive type. Relabeling occurs only when T is a derived type. Promotion and relabeling are therefore never combined.
Note:
A singleton enumeration type such as enum("green") is treated as an atomic type derived by restriction from xs:string; so if the xs:string value "green" is supplied in a context where the required type is enum("red", "green", "blue"), the value will be accepted and will be relabeled as an instance of enum("green").
If R is an ArrayType other than array(*) and J is an array, then J is converted to a new array by converting each member to the required member type by applying the coercion rules recursively.
Note:
For example, if the required type is array(xs:double) and the supplied value is [ 1, 2 ], the array is converted to [ 1e0, 2e0 ].
If R is a MapType other than map(*) and J is a map, then J is converted to a new map as follows:
1. Each key in the supplied map is converted to the required map key type by applying the coercion rules. If the resulting map would contain duplicate keys, a type error is raised [err:XPTY0004].
2. The corresponding value is converted to the required map value type by applying the coercion rules recursively.
3. The order of entries in the map remains unchanged.
4. The order of entries in the map remains unchanged.
Note:
For example, if the required type is map(xs:string, xs:double) and the supplied value is { "x": 1, "y": 2 }, the map is converted to { "x": 1e0, "y": 2e0 }.
Note:
Duplicate keys can occur if the value space of the target type is more restrictive than the original type. For example, an error is raised if the map { 1.2: 0, 1.2000001: 0 }, which contains two keys of type xs:decimal, is coerced to the type map(xs:float, xs:integer).
If R is a RecordType and J is a map, then J is converted to a new map as follows:
1. The keys in the supplied map are unchanged.
2. In any map entry whose key is an xs:string equal to the name of one of the field declarations in R (under the rules of the atomic-equal function), the corresponding value is converted to the required type defined by that field declaration, by applying the coercion rules recursively (but with XPath 1.0 compatibility mode treated as false).
3. The order of entries in the map is changed: entries whose keys correspond to the names of field declarations in R appear first, in the order of the corresponding field declarations, and (if the record type is extensible) other entries then follow retaining their relative order in J.
4. The order of entries in the map is changed: entries whose keys correspond to the names of field declarations in R appear first, in the order of the corresponding field declarations, and (if the record type is extensible) other entries then follow retaining their relative order in J.
Note:
For example, if the required type is record(longitude as xs:double, latitude as xs:double) and the supplied value is { "longitudelatitude": 053.2, "latitudelongitude": 53.20 }, then the map is converted to { "longitude": 0.0e0, "latitude": 53.2e0 }.
If R is a TypedFunctionType and J is a function item, then function coercion is applied to J.
Note:
Function coercion applies even if J is already an instance of R.
Maps and arrays are functions, so function coercion applies to them as well.
If, after the above conversions, the resulting item does not match the expected item type R according to the rules for SequenceType Matching, a type error is raised [err:XPTY0004].
Note:
Under the general rules for type errors (see 2.4.1 Kinds of Errors), a processor may report a type error during static analysis if it will necessarily occur when the expression is evaluated. For example, the function call fn:abs("beer") will necessarily fail when evaluated, because the function requires a numeric value as its argument; this may be detected and reported as a static error.

J Change Log (Non-Normative)

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

XQuery 4.0: An XML Query Language

W3C Editor's Draft 23 February 2026

Abstract

Status of this Document

Dedication

3 Types

3.4 Coercion Rules

3.4.1 Item Coercion Rules

J Change Log (Non-Normative)