Please check the errata for any errors or issues reported since publication.
See also translations.
This document is also available in these non-normative formats: XML.
Copyright © 2000 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
XML is a versatile markup language, capable of labeling the information content of diverse data sources, including structured and semi-structured documents, relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is designed to be broadly applicable across many types of XML data sources.
A list of changes made since XQuery 3.1 can be found in J Change Log.
This is a draft prepared by the QT4CG (officially registered in W3C as the XSLT Extensions Community Group). Comments are invited.
The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).
This section discusses each of the basic kinds of expression. Each kind of expression has a name such as PathExpr, which is introduced on the left side of the grammar production that defines the expression. Since XQuery 4.0 is a composable language, each kind of expression is defined in terms of other expressions whose operators have a higher precedence. In this way, the precedence of operators is represented explicitly in the grammar.
The order in which expressions are discussed in this document does not reflect the order of operator precedence. In general, this document introduces the simplest kinds of expressions first, followed by more complex expressions. For the complete grammar, see Appendix [A XQuery 4.0 Grammar].
[Definition: A query consists of one or more modules.] If a query is executable, one of its modules has a Query Body containing an expression whose value is the result of the query. An expression is represented in the XQuery grammar by the symbol Expr.
Expr | ::= | (ExprSingle ++ ",") |
ExprSingle | ::= | FLWORExpr |
ExprSingle | ::= | FLWORExpr |
FLWORExpr | ::= | InitialClauseIntermediateClause* ReturnClause |
QuantifiedExpr | ::= | ("some" | "every") (QuantifierBinding ++ ",") "satisfies" ExprSingle |
SwitchExpr | ::= | "switch" SwitchComparand (SwitchCases | BracedSwitchCases) |
TypeswitchExpr | ::= | "typeswitch" "(" Expr ")" (TypeswitchCases | BracedTypeswitchCases) |
IfExpr | ::= | "if" "(" Expr ")" (UnbracedActions | BracedAction) |
TryCatchExpr | ::= | TryClause ((CatchClause+ FinallyClause?) | FinallyClause) |
OrExpr | ::= | AndExpr ("or" AndExpr)* |
The XQuery 4.0 operator that has lowest precedence is the comma operator, which is used to combine two operands to form a sequence. As shown in the grammar, a general expression (Expr) can consist of multiple ExprSingle operands, separated by commas.
The name ExprSingle denotes an expression that does not contain a top-level comma operator (despite its name, an ExprSingle may evaluate to a sequence containing more than one item.)
The symbol ExprSingle is used in various places in the grammar where an expression is not allowed to contain a top-level comma. For example, each of the arguments of a function call must be a ExprSingle, because commas are used to separate the arguments of a function call.
After the comma, the expressions that have next lowest precedence are FLWORExpr,QuantifiedExpr, SwitchExpr, TypeswitchExpr, IfExpr, TryCatchExpr, and OrExpr. Each of these expressions is described in a separate section of this document.
XQuery provides node constructors that can create XML nodes within a query.
Constructors are provided for element, attribute, document, text, comment, and processing instruction nodes. Two kinds of constructors are provided: direct constructors, which use an XML-like notation that can incorporate enclosed expressions, and computed constructors, which use a notation based on enclosed expressions.
The rest of this section contains a conceptual description of the semantics of various kinds of constructor expressions. An XQuery implementation is free to use any implementation technique that produces the same result as the processing steps described here.
ComputedConstructor | ::= | CompDocConstructor |
CompDocConstructor | ::= | "document" EnclosedExpr |
CompElemConstructor | ::= | "element" CompNodeNameEnclosedContentExpr |
CompAttrConstructor | ::= | "attribute" CompNodeNameEnclosedExpr |
CompNamespaceConstructor | ::= | "namespace" CompNodeNCNameEnclosedExpr |
CompTextConstructor | ::= | "text" EnclosedExpr |
CompCommentConstructor | ::= | "comment" EnclosedExpr |
CompPIConstructor | ::= | "processing-instruction" CompNodeNCNameEnclosedExpr |
An alternative way to create nodes is by using a computed constructor. A computed constructor begins with a keyword that identifies the type of node to be created: element, attribute, document, text, processing-instruction, comment, or namespace.
For those kinds of nodes that have names (element, attribute, processing instruction, and namespace nodes), the keyword that specifies the node kind is followed by the name of the node to be created. This name may be specified either as an EQName or as an expression enclosed in braces. [Definition: When an expression is used to specify the name of a constructed node, that expression is called the name expression of the constructor.]
The following example illustrates the use of computed element and attribute constructors in a simple case where the names of the constructed nodes are constants. This example generates exactly the same result as the first example in 4.12.1 Direct Element Constructors:
element book {
attribute isbn { "isbn-0060229357" },
element title { "Harold and the Purple Crayon" },
element author {
element first { "Crockett" },
element last { "Johnson" }
}
}Note:
XQuery 4.0 allows the node name to be written in quotation marks (for example, element "book" {}, and at the same time it disallows the use of a defined set of language keywords without quotes: for example element div {} was allowed in XQuery 3.1 but must now be written element "div" {} or element { "div" } {}. The reason for this incompatible change is that allowing map constructors to omit the map keyword would otherwise create an ambiguity: consider for example the expression element otherwise {}.
Because the list of reserved keywords may be extended in future versions of this specification, the safest strategy is to always to use quotation marks (for example element "div") when the node name is a simple NCName. To avoid any dependency on the default namespace context, the form element Q{}div might also be used.
To write code that is portable between XQuery 3.1 and XQuery 4.0, the best advice is to use either the form element { "div" } or the form element Q{}div.
CompPIConstructor | ::= | "processing-instruction" CompNodeNCNameEnclosedExpr |
CompNodeNCName | ::= | MarkedNCName | UnreservedNCName | ("{" Expr "}") |
MarkedNCName | ::= | "#" NCName |
| /* ws: explicit */ | ||
UnreservedNCName | ::= | NCName |
| /* xgc: unreserved-name */ | ||
Expr | ::= | (ExprSingle ++ ",") |
EnclosedExpr | ::= | "{" Expr? "}" |
A computed processing instruction constructor (CompPIConstructor) constructs a new processing instruction node with its own node identity.
The name of a processing-instruction node is always an NCName, and may be provided in a number of ways:
As an NCName with a preceding # sign, for example processing-instruction #xref {}.
As a simple NCName without the preceding #, for example processing-instruction xref {}. This form is allowed only if the name is not a reserved keyword: see unreserved-name.
As an expression in curly braces. This is processed as follows:
Atomization is applied to the value of the name expression. If the result of atomization is not a single atomic item of type xs:NCName, xs:string, or xs:untypedAtomic, a type error is raised [err:XPTY0004].
If the atomized value of the name expression is of type xs:string or xs:untypedAtomic, that value is cast to the type xs:NCName. If the value cannot be cast to xs:NCName, a dynamic error is raised [err:XQDY0041].
The resulting NCName is then used as the target property of the newly constructed processing instruction node. However, a dynamic error is raised if the NCName is equal to "XML" (in any combination of upper and lower case) [err:XQDY0064].
The content expression of a computed processing instruction constructor is processed as follows:
Atomization is applied to the value of the content expression, converting it to a sequence of atomic items. (If the content expression is absent, the result of this step is an empty sequence.)
If the result of atomization is an empty sequence, it is replaced by a zero-length string. Otherwise, each atomic item in the atomized sequence is cast into a string. If any of the resulting strings contains the string "?>", a dynamic error [err:XQDY0026] is raised.
The individual strings resulting from the previous step are merged into a single string by concatenating them with a single space character between each pair. Leading whitespace is removed from the resulting string. The resulting string then becomes the content property of the constructed processing instruction node.
The remaining properties of the new processing instruction node are determined as follows:
The parent property is empty.
The base-uri property is empty.
The following example illustrates a computed processing instruction constructor:
let $target := "audio-output",
return processing-instruction { $target } { "beep" }The processing instruction node constructed by this example might be serialized as follows:
<?audio-output beep?>
CompNamespaceConstructor | ::= | "namespace" CompNodeNCNameEnclosedExpr |
CompNodeNCName | ::= | MarkedNCName | UnreservedNCName | ("{" Expr "}") |
MarkedNCName | ::= | "#" NCName |
| /* ws: explicit */ | ||
UnreservedNCName | ::= | NCName |
| /* xgc: unreserved-name */ | ||
Expr | ::= | (ExprSingle ++ ",") |
EnclosedExpr | ::= | "{" Expr? "}" |
A computed namespace constructor creates a new namespace node, with its own node identity. The parent of the newly created namespace node is absent.
The name of a namespace node is always an NCName, and represents the namespace prefix.
The string value of a namespace node should be a URI, and represents the namespace URI.
The namespace prefix may be provided in a number of ways:
As an NCName with a preceding # sign, for example namespace #xlink { "http://www.w3.org/1999/xlink" }.
As a simple NCName with no preceding # sign, for example namespace xlink { "http://www.w3.org/1999/xlink" }. This form is allowed only if the namespace prefix is not a reserved keyword: see unreserved-name.
As an expression in curly braces. This is processed as follows:
Atomization is applied to the result of the enclosed expression.
If the result of atomization is an empty sequence or a single atomic item of type xs:string or xs:untypedAtomic, then the following rules are applied in order:
If the result is castable to xs:NCName, then it is used as the local name of the newly constructed namespace node. (The local name of a namespace node represents the prefix part of the namespace binding.)
If the result is the empty sequence or a zero-length xs:string or xs:untypedAtomic item, the new namespace node has no name (such a namespace node represents a binding for the default namespace).
Otherwise, a dynamic error is raised [err:XQDY0074].
If the result of atomization is not an empty sequence or a single atomic item of type xs:string or xs:untypedAtomic, a type error is raised [err:XPTY0004].
The content expression is evaluated, and the result is cast to xs:anyURI to create the URI property for the newly created node. An implementation may raise a dynamic error [err:XQDY0074] if the URIExpr of a computed namespace constructor is not a valid instance of xs:anyURI.
An error [err:XQDY0101] is raised if a computed namespace constructor attempts to do any of the following:
Bind the prefix xml to some namespace URI other than http://www.w3.org/XML/1998/namespace.
Bind a prefix other than xml to the namespace URI http://www.w3.org/XML/1998/namespace.
Bind the prefix xmlns to any namespace URI.
Bind a prefix to the namespace URI http://www.w3.org/2000/xmlns/.
Bind any prefix (including the empty prefix) to a zero-length namespace URI.
By itself, a computed namespace constructor has no effect on the in-scope namespaces of any element, but if an element constructor’s content sequence contains a namespace node, the namespace binding it represents is added to that element’s in-scope namespaces.
A computed namespace constructor has no effect on the statically known namespaces in the static context.
Note:
The newly created namespace node has all properties defined for a namespace node in the data model, but its parent is always absent. As defined in the data model, the name of the node is the prefix, the string value of the node is the URI. Since the nodes are parentless, their relative order is implementation dependent.
Examples:
A computed namespace constructor with a prefix:
namespace a { "http://a.example.com" }A computed namespace constructor with a prefix expression:
namespace { "a" } { "http://a.example.com" }A computed namespace constructor with an empty prefix:
namespace "" { "http://a.example.com" }Computed namespace constructors are generally used to add to the in-scope namespaces of elements created with element constructors:
<age xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> {
namespace xs { "http://www.w3.org/2001/XMLSchema" },
attribute xsi:type { "xs:integer" },
23
}</age>In the above example, note that the xsinamespace binding is created for the element because it is used in an attribute name. The attribute’s content is simply character data, and has no effect on namespace bindings. The computed namespace constructor ensures that the xs binding is created.
Computed namespace constructors have no effect on the statically known namespaces. If the prefix a is not already defined in the statically known namespaces, the following expression results in a static error [err:XPST0081].
<a:form>{
namespace a { "http://a.example.com" }
}</a:form>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.
The terms FunctionType, ArrayType, MapType, and RecordType replace FunctionTest, ArrayTest, MapTest, and RecordTest, with no change in meaning.
Record types are added as a new kind of ItemType, constraining the value space of maps.
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.
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
The symbols × and ÷ can be used for multiplication and division.
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.
Operators such as < and > can use the full-width forms < and > to avoid the need for XML escaping.
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.
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.
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.
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.
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.
The arrow operator => is now complemented by a “mapping arrow” operator =!> which applies the supplied function to each item in the input sequence independently.
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.
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).
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.
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.
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.
The syntax document-node(N), where N is a NameTestUnion, is introduced as an abbreviation for document-node(element(N)). For example, document-node(*) matches any well-formed XML document (as distinct from a document fragment).
See 3.2.7 Node Types
QName literals are new in 4.0.
PR 159
Keyword arguments are allowed on static function calls, as well as positional arguments.
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.
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.
PR 254
The term "function conversion rules" used in 3.1 has been replaced by the term "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.
The value bound to a variable in a let clause is now converted to the declared type by applying the coercion rules.
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.
PR 284
Alternative syntax for conditional expressions is available: if (condition) { X }.
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.
PR 324
String templates provide a new way of constructing strings: for example `{$greeting}, {$planet}!` is equivalent to $greeting || ', ' || $planet || '!'
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.
PR 364
Switch expressions now allow a case clause to match multiple atomic items.
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.
PR 433
Numeric literals can now be written in hexadecimal or binary notation; and underscores can be included for readability.
PR 483
The start clause in window expressions has become optional, as well as the when keyword and its associated expression.
PR 493
A new variable $err:map is available, capturing all error information in one place.
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.
PR 521
New abbreviated syntax is introduced (focus function) for simple inline functions taking a single argument. An example is fn { ../@code }
PR 587
Switch and typeswitch expressions can now be written with curly brackets, to improve readability.
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.
PR 606
Element and attribute tests of the form element(A|B) and attribute(A|B) are now allowed.
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.
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.
PR 678
The comparand expression in a switch expression can be omitted, allowing the switch cases to be provided as arbitrary boolean expressions.
PR 682
The values true() and false() are allowed in function annotations, and negated numeric literals are also allowed.
PR 691
Enumeration types are added as a new kind of ItemType, constraining the value space of strings.
PR 728
The syntax record(*) is allowed; it matches any map.
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.
PR 815
The coercion rules now allow conversion in either direction between xs:hexBinary and xs:base64Binary.
PR 820
The value bound to a variable in a for clause is now converted to the declared type by applying the coercion rules.
PR 837
A deep lookup operator ?? is provided for searching trees of maps and arrays.
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.
PR 943
A FLWOR expression may now include a while clause, which causes early exit from the iteration when a condition is encountered.
PR 996
The value of a predicate in a filter expression can now be a sequence of integers.
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.
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.
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.
PR 1132
Choice item types (an item type allowing a set of alternative item types) are introduced.
PR 1163
Filter expressions for maps and arrays are introduced.
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.
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.
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.
PR 1197
The keyword fn is allowed as a synonym for function in function types, to align with changes to inline function declarations.
In inline function expressions, the keyword function may be abbreviated as fn.
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.
PR 1217
Predicates in filter expressions for maps and arrays can now be numeric.
PR 1249
A for key/value clause is added to FLWOR expressions to allow iteration over a map.
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.
PR 1254
The rules concerning the interpretation of xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes have been tightened up.
PR 1265
The rules regarding the document-uri property of nodes returned by the fn:collection function have been relaxed.
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.
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.
The static typing option has been dropped.
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.
PR 1432
In earlier versions, the static context for the initializing expression excluded the variable being declared. This restriction has been lifted.
PR 1470
$err:stack-trace provides information about the current state of execution.
PR 1496
The context value static type, which was there purely to assist in static typing, has been dropped.
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.
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.
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.
PR 1532
Four new axes have been defined: preceding-or-self, preceding-sibling-or-self, following-or-self, and following-sibling-or-self.
See 4.6.4.1 Axes
PR 1577
The syntax record() is allowed; the only thing it matches is an empty map.
PR 1686
With the pipeline operator ->, the result of an expression can be bound to the context value before evaluating another expression.
PR 1696
Parameter names may be included in a function signature; they are purely documentary.
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.
PR 1874
The coercion rules now reorder the entries in a map when the required type is a record type.
PR 1898
The rules for subtyping of document node types have been refined.
PR 1914
A finally clause can be supplied, which will always be evaluated after the expressions of the try/catch clauses.
PR 1956
Private variables declared in a library module are no longer required to be in the module namespace.
Private functions declared in a library module are no longer required to be in the module namespace.
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.
PR 1991
Named record types used in the signatures of built-in functions are now available as standard in the static context.