The grammar of XQuery 4.0 is defined using a version of EBNF defined in . The notation is based on the EBNF dialect used in the XML specification, with two notable additions derived from the Invisible XML grammar:

(A ++ ",") represents a sequence of one or more comma-separated occurrences of A.

(A ** ",") represents a sequence of zero or more comma-separated occurrences of A.

For example the following production rule indicates that an Expr consists of one or more occurrences of ExprSingle, separated by commas:

In principle any production can be used for the separator, but in practice this notation is only used in cases where the separator is a simple constant string.

EBNF grammar rules appear throughout the specification for ease of reference, and the entire grammar is summarized in . For XQuery 4.0, the top-level production rule is Module, representing an XQuery module.

Many grammatical production rules for expressions take a form similar to:

In describing the semantics of the language, we adopt the convention that a term such as range expression (written in bold, or hyperlinked to its definition) refers to a non-trivial instance of the production named RangeExpr. More specifically, it refers to an instance of the production in which the optional part (to AdditiveExpr) is actually present. The construct $n + 1, being an AdditiveExpr, is technically an instance of RangeExpr, but it is not a range expression under this definition.

A construct is said to be a non-trivial instance of a grammatical production if it is not also an instance of one of its sub-productions.

In the data model, a value is always a sequence.

A sequence is an ordered collection of zero or more items.

An item is either an atomic item, a node, or a function item.

An atomic item is a value in the value space of an atomic type, as defined in or .

An XNode is an instance of one of the node kinds defined in . Each XNode has a unique node identity, a typed value, and a string value. In addition, some XNodes have a name. The typed value of an XNode is a sequence of zero or more atomic items. The string value of an XNode is a value of type xs:string. The name of an XNode is a value of type xs:QName.

Except where the context indicates otherwise, the term node is used as a synonym for .

A JNode (see also ) is an encapsulation of a value as it appears within a tree of maps and arrays, typically (but not necessarily) obtained by parsing JSON texts.

A GNode (for generalized node) is either an or a .

A function item is an item that can be called using a .

Maps (see ) and arrays (see ) are specific kinds of s.

A sequence containing exactly one item is called a singleton. An item is identical to a singleton sequence containing that item. Sequences are never nested—for example, combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3).

The sequence containing zero items is called the empty sequence.

The term XDM instance is used, synonymously with the term value, to denote an unconstrained sequence of items.

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

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

The default in-scope namespace of an element node is the namespace URI to which the empty prefix is bound in the element’s . In the absence of an explicit binding for the empty prefix, the default in-scope namespace is .

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

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

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

local-name only (for example, invoice).

A name written in this form has no prefix, and the rules for determining the namespace depend on the context in which the name appears: the various rules used are summarized in . This form is a lexical QName.

A lexical QName is a name that conforms to the syntax of the QName production.

The namespace URI value in a URIQualifiedName is whitespace normalized according to the rules for the xs:anyURI type in or . It is a static error if the namespace URI for an EQName is http://www.w3.org/2000/xmlns/.

Here are some examples of EQNames:

This document uses the following namespace prefixes to represent the namespace URIs with which they are listed.

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

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

When a appearing in an XQuery 4.0 expression is expanded, the rules are as follows.

If the name contains a colon, then the prefix (the substring before the colon) is used to establish the corresponding URI by reference to the in the . If there is no binding for the prefix in the then a static error is raised .

If the lexical QName contains no colon (and therefore no prefix), the namespace URI part of the QName is inferred in one of a number of ways, depending on the syntactic context in which the name appears. The various rules are defined below, and are referred to throughout the specification.

The static context of an expression is the information that is available during static analysis of the expression, prior to its evaluation. This information can be used to decide whether the expression contains a static error.

The individual components of the static context are described below.

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

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

Appendix gives an overview of the components in the static context and the way they are initialized.

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

The dynamic context of an expression is defined as information that is needed for the dynamic evaluation of an expression, beyond any information that is needed from the . If evaluation of an expression relies on some part of the that is , a is raised .

The individual components of the dynamic context are described below.

In general, the dynamic context for the outermost expression is supplied externally, often by some kind of application programming interface (API) allowing XQuery 4.0 expressions to be invoked from a host language. Application Programming Interfaces are outside the scope of this specification. In XQuery 4.0, some aspects of the dynamic context (for example, initial values of variables) are defined within the query prolog. The dynamic context for inner subexpressions may be set by their containing expressions: for example in a mapping expression E1!E2 , the value of the (part of the dynamic context) for evaluation of E2 is defined by the evaluation of E1.

Some aspects of the dynamic context are outside the direct control of the query author; they are defined by the implementation, which may or may not allow them to be configured by users. An example is , which is an abstraction for the set of XML documents that can be retrieved by URI from within an expression. In some environments this may be the entire contents of the web; in others it may be constrained to documents that satisfy particular security constraints; and in some environments the set of available documents might even be empty. These components of the dynamic context are generally treated as being constant for the duration of the execution.

Rules governing the initialization and alteration of these components can be found in .

The components of the are listed below.

The first three components of the dynamic context (context value, context position, and context size) are called the focus of the expression. The focus enables the processor to keep track of which items are being processed by the expression. If any component in the focus is defined, all components of the focus are defined.

A fixed focus is a focus for an expression that is evaluated once, rather than being applied to a series of values; in a fixed focus, the context value is set to one specific value, the context position is 1, and the context size is 1.

A singleton focus is a in which the is a item.. With a singleton focus, the context value is a single item, the context position is 1, and the context size is 1.

Certain language constructs, notably the path operator E1/E2 , the simple map operator E1!E2 , and the predicate E1[E2], create a new focus for the evaluation of a sub-expression. In these constructs, E2 is evaluated once for each item in the sequence that results from evaluating E1. Each time E2 is evaluated, it is evaluated with a different focus. The focus for evaluating E2 is referred to below as the inner focus, while the focus for evaluating E1 is referred to as the outer focus. The inner focus is used only for the evaluation of E2. Evaluation of E1 continues with its original focus unchanged.

As described in , XQuery 4.0 defines a static analysis phase, which does not depend on input data, and a dynamic evaluation phase, which does depend on input data. Errors may be raised during each phase.

An error that can be detected during the static analysis phase, and is not a type error, is a static error. A syntax error is an example of a static error.

A dynamic error is an error that must be detected during the dynamic evaluation phase and may be detected during the static analysis phase. Numeric overflow is an example of a dynamic error.

A type error may be raised during the static analysis phase or the dynamic evaluation phase. During the static analysis phase, a type error occurs when the static type of an expression does not match the expected type of the context in which the expression occurs. During the dynamic evaluation phase, a type error occurs when the dynamic type of a value does not match the expected type of the context in which the value occurs.

The outcome of the static analysis phase is either success or one or more type errors, static errors, or statically detected dynamic errors. The result of the dynamic evaluation phase is either a result value, a type error, or a dynamic error.

If more than one error is present, or if an error condition comes within the scope of more than one error defined in this specification, then any non-empty subset of these errors may be reported.

If an implementation can determine during the static analysis phase that a QueryBody , if evaluated, would necessarily raise a dynamic error or that an expression, if evaluated, would necessarily raise a type error, the implementation may (but is not required to) report that error during the static analysis phase.

An implementation can raise a dynamic error for a QueryBody statically only if the query can never execute without raising that error, as in the following example:

The following example contains a type error, which can be reported statically even if the implementation can not prove that the expression will actually be evaluated.

In addition to static errors, dynamic errors, and type errors, an XQuery 4.0 implementation may raise warnings, either during the static analysis phase or the dynamic evaluation phase. The circumstances in which warnings are raised, and the ways in which warnings are handled, are implementation-defined.

In addition to the errors defined in this specification, an implementation may raise a dynamic error for a reason beyond the scope of this specification. For example, limitations may exist on the maximum numbers or sizes of various objects. An error must be raised if such a limitation is exceeded .

The errors defined in this specification are identified by QNames that have the form err:XXYYnnnn, where:

Except as noted in this document, if any operand of an expression raises a dynamic error, the expression also raises a dynamic error. If an expression can validly return a value or raise a dynamic error, the implementation may choose to return the value or raise the dynamic error (see ). For example, the logical expression expr1 and expr2 may return the value false if either operand returns false, or may raise a dynamic error if either operand raises a dynamic error.

If more than one operand of an expression raises an error, the implementation may choose which error is raised by the expression. For example, in this expression:

both the sub-expressions ($x div $y) and xs:decimal($z) may raise an error. The implementation may choose which error is raised by the + expression. Once one operand raises an error, the implementation is not required, but is permitted, to evaluate any other operands.

In addition to its identifying QName, a dynamic error may also carry a descriptive string and one or more additional values called error values. An implementation may provide a mechanism whereby an application-defined error handler can process error values and produce diagnostic messages. XQuery 3.1 provides standard error handling via .

A dynamic error may be raised by a system function or operator. For example, the div operator raises an error if its operands are xs:decimal values and its second operand is equal to zero. Errors raised by system functions and operators are defined in or the host language.

A dynamic error can also be raised explicitly by calling the fn:error function, which always raises a dynamic error and never returns a value. This function is defined in . For example, the following function call raises a dynamic error, providing a QName that identifies the error, a descriptive string, and a diagnostic value (assuming that the prefix app is bound to a namespace containing application-defined error codes):

Because different implementations may choose to evaluate or optimize an expression in different ways, certain aspects of raising dynamic errors are implementation-dependent, as described in this section.

An implementation is always free to evaluate the operands of an operator in any order.

In some cases, a processor can determine the result of an expression without accessing all the data that would be implied by the formal expression semantics. For example, the formal description of filter expressions suggests that $s[1] should be evaluated by examining all the items in sequence $s, and selecting all those that satisfy the predicate position()=1. In practice, many implementations will recognize that they can evaluate this expression by taking the first item in the sequence and then exiting. If $s is defined by an expression such as //book[author eq 'Berners-Lee'], then this strategy may avoid a complete scan of a large document and may therefore greatly improve performance. However, a consequence of this strategy is that a dynamic error or type error that would be detected if the expression semantics were followed literally might not be detected at all if the evaluation exits early. In this example, such an error might occur if there is a book element in the input data with more than one author subelement.

The extent to which a processor may optimize its access to data, at the cost of not raising errors, is defined by the following rules.

Consider an expression Q that has an operand (sub-expression) E. In general the value of E is a sequence. At an intermediate stage during evaluation of the sequence, some of its items will be known and others will be unknown. If, at such an intermediate stage of evaluation, a processor is able to establish that there are only two possible outcomes of evaluating Q, namely the value V or an error, then the processor may deliver the result V without evaluating further items in the operand E. For this purpose, two values are considered to represent the same outcome if their items are pairwise the same, where nodes are the same if they have the same identity, and values are the same if they are equal and have exactly the same type.

There is an exception to this rule: If a processor evaluates an operand E (wholly or in part), then it is required to establish that the actual value of the operand E does not violate any constraints on its cardinality. For example, the expression $e eq 0 results in a type error if the value of $e contains two or more items. A processor is not allowed to decide, after evaluating the first item in the value of $e and finding it equal to zero, that the only possible outcomes are the value true or a type error caused by the cardinality violation. It must establish that the value of $e contains no more than one item.

These rules apply to all the operands of an expression considered in combination: thus if an expression has two operands E1 and E2, it may be evaluated using any samples of the respective sequences that satisfy the above rules.

The rules cascade: if A is an operand of B and B is an operand of C, then the processor needs to evaluate only a sufficient sample of B to determine the value of C, and needs to evaluate only a sufficient sample of A to determine this sample of B.

The effect of these rules is that the processor is free to stop examining further items in a sequence as soon as it can establish that further items would not affect the result except possibly by causing an error. For example, the processor may return true as the result of the expression S1 = S2 as soon as it finds a pair of equal values from the two sequences.

Another consequence of these rules is that where none of the items in a sequence contributes to the result of an expression, the processor is not obliged to evaluate any part of the sequence. Again, however, the processor cannot dispense with a required cardinality check: if the empty sequence is not permitted in the relevant context, then the processor must ensure that the operand is not the empty sequence.

Examples:

For a variety of reasons, including optimization, implementations may rewrite expressions into a different form. There are a number of rules that limit the extent of this freedom:

An expression E is said to be guarded by some governing condition C if evaluation of E is not allowed to fail with a except when C applies.

For example, in a conditional expression if (P) then T else F, the subexpression T is guarded by P, and the subexpression F is guarded by not(P). One way an implementation can satisfy this rule is by not evaluating T unless P is true, and likewise not evaluating F unless P is false. Another way of satisfying the rule is for the implementation to evaluate all the subexpressions, but to catch any errors that occur in a guarded subexpression so they are not propagated.

The existence of this rule enables errors to be prevented by writing expressions such as if ($y eq 0) then "N/A" else ($x div $y). This example will never fail with a divide-by-zero error because the else branch of the conditional is .

Similarly, in the mapping expression E1!E2 , the subexpression E2 is guarded by the existence of an item from E1. This means, for example, that the expression (1 to $n)!doc('bad.xml') must not raise a dynamic error if $n is zero. The rule governing evaluation of guarded expressions is phrased so as not to disallow “loop-lifting” or “constant-folding” optimizations whose aim is to avoid repeated evaluation of a common subexpression; but such optimizations must not result in errors that would not otherwise occur.

The complete list of expressions that have guarded subexpressions is as follows:

The fact that an expression is does not remove the obligation to report static errors in the expression; nor does it remove the option to report statically detectable type errors.

Certain expressions, while not erroneous, are classified as being implausible, because they achieve no useful effect.

An example of an implausible expression is @code/text(). This expression will always evaluate to the empty sequence, because attribute nodes cannot have text node children. The semantics of the expression are well defined, but it is likely that the user writing this expression intended something different: if they wanted to write an expression that evaluated to the empty sequence, there would be easier ways to write it.

Where an expression is classified (by rules in this specification) as being , a processor may (but is not required to) raise a static error.

For reasons of backwards compatibility and interoperability, and to facilitate automatic generation of XQuery 4.0 code, a processor must provide a mode of operation in which expressions are not treated as static errors, but are evaluated with the defined semantics for the expression.

Some other examples of implausible expressions include:

An ordering called document order is defined among all the nodes accessible during processing of a given query , which may consist of one or more trees (documents or fragments).

Document order applies both to XNodes (typically corresponding to nodes in an XML document, and generally referred to simply as nodes), and also to JNodes, often corresponding to the contents of a JSON source text. These are known collectively as GNodes (for "generalized node").

Document order is defined in , and its definition is repeated here for convenience. Document order is a total ordering, although the relative order of some nodes is implementation-dependent. Informally, document order is the order in which nodes appear in the XML serialization of a document. Document order is stable, which means that the relative order of two nodes will not change during the processing of a given query , even if this order is implementation-dependent. The node ordering that is the reverse of document order is called reverse document order.

Within an , (that is, a tree consisting of XNodes), document order satisfies the following constraints:

Similarly, within an , (that is, a tree consisting of JNodes), document order satisfies the following constraints:

The relative order of nodes in distinct trees is stable but implementation-dependent, subject to the following constraint: If any node in a given tree T1 is before any node in a different tree T2, then all nodes in tree T1 are before all nodes in tree T2.

Every node (that is, every ) has a typed value and a string value, except for nodes whose value is . The typed value of a node is a sequence of atomic items and can be extracted by applying the data function to the node. The string value of a node is a string and can be extracted by applying the string function to the node.

An implementation may store both the typed value and the string value of a node, or it may store only one of these and derive the other as needed. The string value of a node must be a valid lexical representation of the typed value of the node, but the node is not required to preserve the string representation from the original source document. For example, if the typed value of a node is the xs:integer value 30, its string value might be "30" or "0030".

The typed value, string value, and type annotation of a node are closely related, and are defined by rules found in the following locations:

The relationship between typed value and string value for various kinds of nodes is summarized and illustrated by examples below.

The semantics of some XQuery 4.0 operators depend on a process called atomization. Atomization is applied to a value when the value is used in a context in which a sequence of atomic items is required. The result of atomization is either a sequence of atomic items or a type error . Atomization of a sequence is defined as the result of invoking the fn:data function, as defined in .

The semantics of fn:data are repeated here for convenience. The result of fn:data is the sequence of atomic items produced by applying the following rules to each item in the input sequence:

Atomization is used in processing many expressions that are designed to operate on atomic items, including:

Atomization plays an important role in the used when converting a supplied argument in a function call to the type declared in the function signature.

Under certain circumstances (some of which are listed below), it is necessary to find the effective boolean value of a value. The effective boolean value of a value is defined as the result of applying the fn:boolean function to the value.

The dynamic semantics of fn:boolean are repeated here for convenience:

The effective boolean value of a sequence is computed implicitly during processing of the following types of expressions:

XQuery 4.0 requires a statically known, valid URI in a URILiteral or a BracedURILiteral. An implementation may raise a static error if the value of a URI Literal or a Braced URI Literal is of nonzero length and is neither an absolute URI nor a relative URI.

As in a string literal, any predefined entity reference (such as &), character reference (such as •), or EscapeQuot or EscapeApos (for example, "") is replaced by its appropriate expansion. Certain characters, notably the ampersand, can only be represented using a predefined entity reference or a character reference.

Whitespace is normalized using the whitespace normalization rules of fn:normalize-space. If the result of whitespace normalization contains only whitespace, the corresponding URI consists of the empty string. Whitespace normalization is done after the expansion of character references, so writing a newline (for example) as 
 does not prevent its being normalized to a space character.

A Braced URI Literal or URI Literal is not subjected to percent-encoding or decoding as defined in .

Some grammatical contexts allow a Constant to appear. A constant may be a string or numeric literal, but it also allows negative numbers and booleans.

A constant may take any of the following forms:

To resolve a relative URI $rel against a base URI $base is to expand it to an absolute URI, as if by calling the function fn:resolve-uri($rel, $base). During static analysis, the base URI is the Static Base URI. During dynamic evaluation, the base URI used to resolve a relative URI reference depends on the semantics of the expression.

Any process that attempts to resolve a URI against a base URI, or to dereference the URI, may apply percent-encoding or decoding as defined in the relevant RFCs.

Here are some examples of sequence types that might be used in XQuery 4.0:

SequenceType matching compares a value with an expected sequence type. For example, an instance of expression returns true if a given value matches a given sequence type, and false if it does not.

An XQuery 4.0 implementation must be able to determine relationships among the types in type annotations in an XDM instance and the types in the in-scope schema definitions (ISSD). An XQuery 4.0 implementation must be able to determine relationships among the types in ISSDs used in different modules of the same query.

The use of a value that has a that is a of the expected type is known as subtype substitution. Subtype substitution does not change the actual type of a value. For example, if an xs:integer value is used where an xs:decimal value is expected, the value retains its type as xs:integer.

The rules for SequenceType matching are given below, with examples (the examples are for purposes of illustration, and do not cover all possible cases).

An OccurrenceIndicator specifies the number of items in a sequence, as follows:

As a consequence of these rules, any sequence type whose OccurrenceIndicator is * or ? matches a value that is the empty sequence.

Some item types are defined in terms of schema types, and the matching rules for such item types depend on the rules defining relationships between schema types in the XSD specification.

A S1 is said to derive from S2 if any of the following conditions is true:

The XML Schema specification does not completely specify the circumstances under which S1 and S2 are considered to be the same type. For example, if both are anonymous union types with the same member types, but defined in different places in the schema, then schema processors have discretion whether to treat them as the same type.

Atomic types in the XQuery 4.0 type system correspond directly to atomic types as defined in the or type system.

Atomic types are either built-in atomic types such as xs:integer, or user-defined atomic types imported from a schema. Atomic types are identified by a QName: see .

A generalized atomic type is an whose instances are all atomic items. Generalized atomic types include (a) atomic types, either built-in (for example xs:integer) or imported from a schema, (b) pure union types, either built-in (xs:numeric and xs:error) or imported from a schema, (c) choice item types if their alternatives are all generalized atomic types, and (d) enumeration types. .

A may be designated by an ItemType in any of the following ways:

An atomic item A matches the GAT if the type annotation of A GAT.

Example: The ItemType xs:decimal matches any value of type xs:decimal. It also matches any value of type shoesize, if shoesize is an derived by restriction from xs:decimal.

Example: Suppose ItemType dress-size is a union type that allows either xs:decimal values for numeric sizes (for example: 4, 6, 10, 12), or one of an enumerated set of xs:strings (for example: small, medium, large). The ItemType dress-size matches any of these values.

Union types, as defined in XSD, are a variety of simple types. The membership of a union type in XSD may include list types as well as atomic types and other union types.

A pure union type is a simple type that satisfies the following constraints: (a) {variety} is union, (b) the {facets} property is empty, (c) no type in the transitive membership of the union type has {variety} list, and (d) no type in the transitive membership of the union type is a type with {variety} union having a non-empty {facets} property.

The type xs:numeric is defined as a union type with member types xs:double, xs:float, and xs:decimal. An item that is an instance of any of these types is referred to as a numeric value, and a type that is a subtype of xs:numeric is referred to as a numeric type.

The namespace-sensitive types are xs:QName, xs:NOTATION, types derived by restriction from xs:QName or xs:NOTATION, list types that have a namespace-sensitive item type, and union types with a namespace-sensitive type in their transitive membership.

It is not possible to preserve the type of a namespace-sensitive value without also preserving the that defines the meaning of each namespace prefix used in the value. Therefore, XQuery 4.0 defines some error conditions that occur only with namespace-sensitive values. For instance, casting to a namespace-sensitive type raises a type error if the namespace bindings for the result cannot be determined.

A choice item type defines an item type that is the union of a number of alternatives. For example the type (xs:hexBinary | xs:base64Binary) defines the union of these two primitive atomic types, while the type (map(*) | array(*)) matches any item that is either a map or an array.

An item matches a ChoiceItemType if it matches any of the alternatives listed within the parentheses.

For example, the type (xs:NCName | enum("")) matches any value that is either an instance of xs:NCName, or a zero-length string. This might be a suitable type for a variable that holds a namespace prefix.

If all the alternatives are generalized atomic types then the is itself a generalized atomic type, which means, for example, that it can be used as the target of a cast expression.

An EnumerationType accepts a fixed set of string values.

An has a value space consisting of a set of xs:string values. When matching strings against an enumeration type, strings are always compared using the Unicode codepoint collation.

For example, if an argument of a function declares the required type as enum("red", "green", "blue"), then the string "green" is accepted, while "yellow" is rejected with a type error.

Technically, enumeration types are defined as follows:

An enumeration type is a .

It follows from these rules that the expression "red" instance of enum("red", "green", "blue") returns true. By contrast, xs:untypedAtomic("red") instance of enum("red", "green", "blue") returns false; but the ensure that where a variable or function declaration specifies an enumeration type as the required type, an xs:untypedAtomic or xs:anyURI value equal to one of the enumerated values will be accepted.

Node types are item types whose instances are all nodes.

The syntax for node types is also used for node tests within path expressions. This explains why the production rules have names such as NodeTest rather than NodeType.

Some of the constructs described in this section include a TypeName. This appears as T in:

The type name T is expanded using the . The resulting must identify a type in the . This can be any : either a simple type, or (except in the case of attributes) a complex type. If it is a simple type then it can be an atomic, union, or list type. It can be a built-in type (such as xs:integer) or a user-defined type. It must however be the name of a type defined in a schema; it cannot be a .

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

The relation among these types is described in the various subsections of .

A JNodeType matches a .

Specifically:

For example:

A GNodeType matches a generalized node (): that is, it matches any or .

The type gnode() is equivalent to the choice type jnode() | node().

The item type xs:error has an empty value space; it never appears as a dynamic type or as the content type of a dynamic element or attribute type. It was defined in XML Schema in the interests of making the type system complete and closed, and it is also available in XQuery 4.0 for similar reasons.

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

To define the rules, we divide sequence types into six categories:

The judgement A ⊑ B is then determined by the categories of the two sequence types, as defined in the table below. In many cases this depends on the relationship between the item types of A and B. This is denoted using the notation A/i ⊆ B/i , as defined in .

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

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

References to named item types are handled as described in .

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

The judgement subtype-assertions(AnnotationsA, AnnotationsB) determines if AnnotationsA is a subtype of AnnotationsB, where AnnotationsA and AnnotationsB are annotation lists from two FunctionTypes. It is defined to ignore function assertions in namespaces not understood by the XQuery implementation. For assertions that are understood, their effect on the result of subtype-assertions() is implementation defined.

The following examples are some possible ways to define subtype-assertions() for some implementation defined assertions in the local namespace. These examples assume that some implementation uses annotations to label functions as deterministic or nondeterministic, and treats deterministic functions as a subset of nondeterministic functions. In this implementation, nondeterministic functions are not a subset of deterministic functions.

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

An expression is deemed to be if the static type of the expression, after applying all necessary coercions, is substantively disjoint with the required type T.

Two sequence types are deemed to be substantively disjoint if (a) neither is a subtype of the other (see ) and (b) the only values that are instances of both types are one or more of the following:

Examples of pairs of sequence types that are substantively disjoint include:

For example, supplying a value whose static type is xs:integer* when the required type is xs:string* is , because it can succeed only in the special case where the actual value supplied is the empty sequence.

Examples of implausible coercions include the following:

Function coercion is a transformation applied to function items during application of the coercion rules. Function coercion wraps a in a new function whose signature is the same as the expected type. This effectively delays the checking of the argument and return types until the function is called.

Given a function F, and an expected function type T, function coercion proceeds as follows:

These rules have the following consequences:

SequenceType matching of the function’s arguments and result are delayed until that function is called.

For instance, consider the following query: declare function local:filter( $s as item()*, $p as function(xs:string) as xs:boolean ) as item()* { $s[$p(.)] }; let $f := function($a) { starts-with($a, "E") } return local:filter(("Ethel", "Enid", "Gertrude"), $f)

The function $f has a static type of function(item()*) as item()*. When the local:filter() function is called, the following occurs to the function:

The coercion rules result in applying function coercion to $f, wrapping $f in a new function ($p) with the signature function(xs:string) as xs:boolean.

Since maps and arrays are also functions in XQuery 4.0, function coercion applies to them as well. For instance, consider the following expression:

The map $m is an instance of function(xs:anyAtomicType?) as item()*. When the fn:filter() function is called, the following occurs to the map:

The map $m is treated as a function equivalent to map:get($m, ?).

Consider the following expression:

In this case the result of the expression is the sequence ("Monday", "Friday"). But if the input sequence included the string "Tuesday", the filter operation would fail with a type error.

This section illustrates the effect of the coercion rules with examples.

A literal is a direct syntactic representation of an atomic item. XQuery 4.0 supports three kinds of literals: numeric literals, string literals, and QName literals.