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.


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


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.17 Context Value Declaration

Changes in 4.0  

  1. 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.   [Issue 129 PR 368 21 July 2023]

  2. The supplied context value is now coerced to the required type specified in the main module using the coercion rules.   [IssueIssues 189 2040 PRPRs 254 2050 13 June 2025]

ContextValueDecl::="declare" "context" (("value" ("as" SequenceType)?) | ("item" ("as" ItemType)?)) ((":=" VarValue) | ("external" (":=" VarDefaultValue)?))
SequenceType::=("empty-sequence" "(" ")")
| (ItemTypeOccurrenceIndicator?)
ItemType::=AnyItemTest | TypeName | KindTest | FunctionType | MapType | ArrayType | RecordType | EnumerationType | ChoiceItemType
VarValue::=ExprSingle
ExprSingle::=FLWORExpr
| QuantifiedExpr
| SwitchExpr
| TypeswitchExpr
| IfExpr
| TryCatchExpr
| OrExpr
VarDefaultValue::=ExprSingle

A context value declaration allows a query to specify the static type, value, or default value for the initial context value.

Only the main module can set the initial context value. In a library module, a context value declaration must be external, and specifies only the static type. Specifying a VarValue or VarDefaultValue for a context value declaration in a library module is a static error [err:XQST0113].

The form declare context value allows the initial context value to be set to any value, with any sequence type. The alternative form declare context item is retained for compatibility with earlier versions of XQuery, and requires the value to be a single item, and the type (if specified) to be an item type.

In every module that does not contain a context value declaration, the effect is as if the declaration

declare context value as item()* external;

appeared in that module.

The context value declaration has the effect of defining a required type for the context value. When the form declare context value is used, the default type is item()*. When the alternative form declare context item is used, the default type is item().

If a module contains more than one context value declaration, a static error is raised [err:XQST0099].

During query evaluation, a fixed focus is created in the dynamic context for the evaluation of the QueryBody in the main module, and for the initializing expression of every variable declaration in every module. The context value of this fixed focus is called the initial context value, which is selected as follows:

  • If VarValue is specified, then the initial context value is the result of evaluating VarValue, coerced to the required type as described below.

    Note:

    In such a case, the initial context value does not obtain its value from the external environment. If the external environment attempts to provide a value for the initial context value, it is outside the scope of this specification whether that is ignored, or results in an error.

  • If external is specified, then:

    • If the declaration occurs in a main module and a value is provided for the context value by the external environment, then the initial context value is that value, coerced to the required type as described below.

      Note:

      If the declaration occurs in a library module, then it does not set the value of the initial context value, the value is set by the main module.

      The means by which an external value is provided by the external environment is implementation-defined.

    • If no value is provided for the context value by the external environment, and VarDefaultValue is specified, then the initial context value is the result of evaluating VarDefaultValue, coerced to the required type as described below.

If VarValue or VarDefaultValue is evaluated, the static and dynamic contexts for the evaluation are the current module's static and dynamic context. The static context for the initializing expression includes all functions, variables, and namespaces that are declared or imported anywhere in the Prolog.

If a required type is defined in the main module, then the value obtained by evaluating VarValue or VarDefaultValue, or the value supplied externally, is converted to the required type by applying the coercion rules. A type error occurs if this is not possible. In invoking the coercion rules, XPath 1.0 compatibility mode does not apply.

If a required type is defined in any library module, then the value obtained by evaluating VarValue or VarDefaultValue, or the value supplied externally, after coercion to any required type defined in the main module, must match that required type, without any further coercion; otherwise a type error is raised [err:XPTY0004]. If more than one library module contains a context value declaration, the context value must match the type declared in each one.

Here are some examples of context value declarations.

  • Declare the type of the context value as a single element item with a required element name:

    declare namespace env = "http://www.w3.org/2003/05/soap-envelope"; 
    declare context item as element(env:Envelope) external;
  • Declare a default context value, which is a system log in a default location. If the system log is in a different location, it can be specified in the external environment:

    declare context value as element(sys:log) external :=
      doc("/var/xlogs/sysevent.xml")/sys:log;
  • Declare a context value, which is collection whose collection URI is supplied as an external parameter to the query. If the system log is in a different location, it can be specified in the external environment:

    declare variable $uri as xs:string external;
    declare context value as document-node()* := collection($uri);

    With this declaration, a query body such as //person[name="Mandela"] returns all matching person elements appearing in any document in the collection.

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. PR 1480 1989 

    When the element name matches a language keyword such as div or value, it must now be written as a QName literal. This is a backwards incompatible change.

    See 4.12.3.1 Computed Element Constructors

    When the attribute name matches a language keyword such as by or of, it must now be written as a QName literal. This is a backwards incompatible change.

    See 4.12.3.2 Computed Attribute Constructors

  12. PR 1513 2028 

    When the processing instruction name matches a language keyword such as try or validate, it must now be written with a preceding # character. This is a backwards incompatible change.

    See 4.12.3.5 Computed Processing Instruction Constructors

    When the namespace prefix matches a language keyword such as as or at, it must now be written with a preceding # character. This is a backwards incompatible change.

    See 4.12.3.7 Computed Namespace Constructors

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

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

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

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

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

  18. PR 254 2050 

    The supplied context value is now coerced to the required type specified in the main module using the coercion rules.

    See 5.17 Context Value Declaration

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

  20. PR 682 TODO 

    The values true() and false() are allowed in function annotations, as well as negated numeric literals and QName literals.

    See 5.18.4 Function Annotations

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

  22. A dynamic function call can now be applied to a sequence of functions, and in particular to an empty sequence. This makes it easier to chain a sequence of calls.

    See 4.5.3.1 Evaluating Dynamic Function Calls

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

  25. QName literals are new in 4.0.

    See 4.2.1.3 QName Literals

  26. PR 159 

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

    See 4.5.1.1 Static Function Call Syntax

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

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

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

  30. PR 284 

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

    See 4.16 Conditional Expressions

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

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

  33. PR 326 

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

    See 6 Conformance

  34. PR 344 

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

    See 4.13.2 For Clause

  35. PR 364 

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

    See 4.18 Switch Expressions

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

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

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

  39. PR 493 

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

    See 4.20 Try/Catch Expressions

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

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

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

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

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

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

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

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

  48. PR 691 

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

    See 3.2.6 Enumeration Types

  49. PR 728 

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

    See 3.2.8.3 Record Types

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

  51. PR 815 

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

    See 3.4 Coercion Rules

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

  53. PR 837 

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

    See 4.14.3 Lookup Expressions

  54. PR 911 

    The coercion rules now allow any numeric type to be implicitly converted to any other, for example an xs:double is accepted where the required type is xs:decimal.

    See 3.4 Coercion Rules

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

  56. PR 996 

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

    See 4.4 Filter Expressions

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

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

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

  60. PR 1132 

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

    See 3.2.5 Choice Item Types

  61. PR 1163 

    Filter expressions for maps and arrays are introduced.

    See 4.14.4 Filter Expressions for Maps and Arrays

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

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

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

  65. PR 1217 

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

    See 4.14.4 Filter Expressions for Maps and Arrays

  66. PR 1249 

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

    See 4.13.2 For Clause

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

  68. PR 1254 

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

    See 4.25 Validate Expressions

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

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

  71. PR 1344 

    Parts of the static context that were there purely to assist in static typing, such as the statically known documents, were no longer referenced and have therefore been dropped.

    See 2.2.1 Static Context

    The static typing option has been dropped.

    See 2.3 Processing Model

    The static typing feature has been dropped.

    See 6 Conformance

  72. PR 1361 

    The term atomic value has been replaced by atomic item.

    See 2.1.2 Values

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

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

  75. PR 1470 

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

    See 4.20 Try/Catch Expressions

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

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

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

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

  80. PR 1577 

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

    See 3.2.8.3 Record Types

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

  82. PR 1696 

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

    See 3.2.8.1 Function Types

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

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

  85. PR 1898 

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

    See 3.3.2.4.2 Subtyping Nodes: Document Nodes

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

  87. PR 1956 

    Private variables declared in a library module are no longer required to be in the module namespace.

    See 5.16 Variable Declaration

    Private functions declared in a library module are no longer required to be in the module namespace.

    See 5.18.2 Function Names

  88. PR 1982 

    Whitespace is now required after the opening (# of a pragma. This is an incompatible change, made to ensure that an expression such as error(#err:XPTY0004) can be parsed as a function call taking a QName literal as its argument value.

    See 4.26 Extension Expressions

  89. PR 1991 

    Named record types used in the signatures of built-in functions are now available as standard in the static context.

    See 2.2.1 Static Context

  90. PR 2026 

    The module feature is no longer an optional feature; processing of library modules is now required.

    See 6 Conformance

  91. PR 2030 

    The technical details of how validation works have been moved to the Functions and Operators specification. The XQuery validate expression is now defined in terms of the new xsd-validator function.

    See 4.25 Validate Expressions

  92. PR 2050 

    The supplied context value is now coerced to the required type specified in the main module using the coercion rules.

    See 5.17 Context Value Declaration

  93. PR 2055 

    Sequences, arrays, and maps can be destructured in a let clause to extract their components into multiple variables.

    See 4.13.3 Let Clause