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, ordering 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 3 Expressions. A module can be evaluated only if it has a Query Body.
| [2] | VersionDecl |
::= | "xquery" (("encoding" StringLiteral) | ("version"
StringLiteral ("encoding"
StringLiteral)?))
Separator |
[Definition: A version declaration can identify the applicable XQuery syntax and semantics for a module, as well as its encoding.] The version number "1.0" indicates the intent that the module be processed by an XQuery 1.0 processor; the version number "3.0" indicates the intent that the module be processed by an XQuery 3.0 processor. If the version declaration is not present or the version is not included in the declaration, an XQuery 3.0 processor assumes a version of "3.0". If an XQuery 3.0 processor processes a module labeled with a version of "1.0", it must do one of the following:
Process the module using the specification of the XQuery version identified in the version declaration.
Process the module using the specification of XQuery 3.0.
Note:
An implementation may issue a warning in this case.
Raise a static error [err:XQST0031]
A processor may raise an error [err:XQST0034] if the modules of a query do not have the same version number.
Note:
In general, this should be done only if a processor is not able to evaluate such a query.
[Definition: If present, a version
declaration may optionally include an encoding declaration.
The value of the string literal following the keyword
encoding
is an encoding name, and must conform to the
definition of EncName
specified in [XML
1.0] [err:XQST0087]. The purpose of an encoding
declaration is to allow the writer of a query to provide a string
that indicates how the query is encoded, such as
"UTF-8
", "UTF-16
", or
"US-ASCII
".] Since the encoding of a query may change
as the query moves from one environment to another, there can be no
guarantee that the encoding declaration is correct.
The handling of an encoding declaration is implementation-dependent. If an implementation has a priori knowledge of the encoding of a query, it may use this knowledge and disregard the encoding declaration. The semantics of a query are not affected by the presence or absence of an encoding declaration.
If a version declaration is present, no Comment may occur before the end of the version declaration. If such a Comment is present, the result is implementation-dependent ; an implementation may raise an implementation-dependent static error, or ignore the comment.
Note:
The effect of a Comment before the end of a version declaration is implementation-dependent because it may suppress query processing by interfering with detection of the encoding declaration.
The following examples illustrate version declarations:
xquery version "1.0";
xquery version "3.0" encoding "utf-8";
| [5] | ModuleDecl |
::= | "module" "namespace" NCName "=" URILiteral Separator |
[Definition: A module
declaration serves to identify a module as a library module. A module declaration
begins with the keyword module
and contains a
namespace prefix and a URILiteral.] The URILiteral must be
of nonzero length [err:XQST0088]. The URILiteral identifies the
target
namespace of the library module, which is the namespace for all
variables and functions exported by the library module. The name of
every variable and function declared in a library module must have
a namespace URI that is the same as the target namespace of the
module; otherwise a static error is raised [err:XQST0048]. The
(prefix,URI) pair is added to the set of statically known namespaces.
The namespace prefix specified in a module declaration must not
be xml
or xmlns
[err:XQST0070], and must not be the same as
any namespace prefix bound in the same module by a schema import, by a
namespace declaration, or by a
module import
with a different target namespace [err:XQST0033].
Any module may import one or more library modules by means of a module import that specifies the target namespace of the library modules to be imported. When a module imports one or more library modules, the variables and functions declared in the imported modules are added to the static context and (where applicable) to the dynamic context of the importing module.
The following is an example of a module declaration:
module namespace gis = "http://example.org/gis-functions";
In a module's dynamic context, a variable value (or the context item) may depend on another variable value (or the context item). [Definition: a variable value (or the context item) depends on another variable value (or the context item) if, during the evaluation of the initializing expression of the former, the latter is accessed through the module context.]
In the following example, the variable value $a
depend onthe
variable value $b
because the evaluation of $a's
initializing expression accesses the value of $b during the
evaluation of local:f()
.
declare variable $a := local:f(); declare variable $b := 1; declare function local:f() { $b };
A directed graph can be built with all variable values and the context item as nodes, and with the depend on relation as edges. This graph may not contain cycles, as it makes the population of the dynamic context impossible. If it is discovered, during static analysis or during dynamic evaluation, that such a cycle exists, error [err:XQDY0054] must be raised.
| [9] | BoundarySpaceDecl |
::= | "declare" "boundary-space" ("preserve" |
"strip") |
[Definition: A
boundary-space declaration sets the boundary-space policy in the
static
context, overriding any implementation-defined default.
Boundary-space policy controls whether boundary
whitespace is preserved by element constructors during
processing of the query.] If boundary-space policy is
preserve
, boundary whitespace is preserved. If
boundary-space policy is strip
, boundary whitespace is
stripped (deleted). A further discussion of whitespace in
constructed elements can be found in <IP_ADDRESS> Boundary Whitespace.
The following example illustrates a boundary-space declaration:
declare boundary-space preserve;
If a Prolog contains more than one boundary-space declaration, a static error is raised [err:XQST0068].
| [10] | DefaultCollationDecl |
::= | "declare" "default" "collation" URILiteral |
[Definition: A default
collation declaration sets the value of the default collation
in the static
context, overriding any implementation-defined default.] The
default collation is the collation that is used by functions and
operators that require a collation if no other collation is
specified. For example, the gt
operator on strings is
defined by a call to the fn:compare
function, which
takes an optional collation parameter. Since the gt
operator does not specify a collation, the fn:compare
function implements gt
by using the default
collation.
If neither the implementation nor the Prolog specifies a default
collation, the Unicode codepoint collation
(http://www.w3.org/2005/xpath-functions/collation/codepoint
)
is used.
The following example illustrates a default collation declaration:
declare default collation "http://example.org/languages/Icelandic";
If a default collation declaration specifies a collation by a relative URI, that relative URI is resolved to an absolute URI using the Static Base URI. If a Prolog contains more than one default collation declaration, or the value specified by a default collation declaration (after resolution of a relative URI, if necessary) is not present in statically known collations, a static error is raised [err:XQST0038].
| [11] | BaseURIDecl |
::= | "declare" "base-uri" URILiteral |
[Definition: A base URI
declaration specifies the Static Base URI property. The
Static Base
URI property is used when resolving relative URI
references. ] For example, the Static Base URI
property is used when resolving relative references for module import and for
the fn:doc
function.
Note:
As discussed in the definition of , if there is no base URI declaration, or if the value of the declaration is a relative URI reference, then the value of the Static Base URI may depend on the location of the query, and it is permissible for this to vary between the static analysis phase and the dynamic evaluation phase.
The following is an example of a base URI declaration:
declare base-uri "http://example.org";
If a Prolog contains more than one base URI declaration, a static error is raised [err:XQST0032].
In the terminology of [RFC3986] Section
5.1, the URILiteral of the base URI declaration is considered to be
a "base URI embedded in content". If no base URI declaration is
present, Static Base URI property is
established according to the principles outlined in [RFC3986] Section 5.1—that is, it defaults first to
the base URI of the encapsulating entity, then to the URI used to
retrieve the entity, and finally to an implementation-defined
default. If the URILiteral in the base URI declaration is a
relative URI, then it is made absolute by resolving it with respect
to this same hierarchy. For example, if the URILiteral in the base
URI declaration is ../data/
, and the query is
contained in a file whose URI is
file:///C:/temp/queries/query.xq
, then the
Static
Base URI property is
file:///C:/temp/data/
.
It is not intrinsically an error if this process fails to establish an absolute base URI; however, the Static Base URI property is then
| [12] | ConstructionDecl |
::= | "declare" "construction" ("strip" |
"preserve") |
[Definition: A construction
declaration sets the construction mode in the static context,
overriding any implementation-defined default.] The construction
mode governs the behavior of element and document node
constructors. If construction mode is preserve
, the
type of a constructed element node is xs:anyType
, and
all attribute and element nodes copied during node construction
retain their original types. If construction mode is
strip
, the type of a constructed element node is
xs:untyped
; all element nodes copied during node
construction receive the type xs:untyped
, and all
attribute nodes copied during node construction receive the type
xs:untypedAtomic
.
The following example illustrates a construction declaration:
declare construction strip;
If a Prolog specifies more than one construction declaration, a static error is raised [err:XQST0067].
| [13] | OrderingModeDecl |
::= | "declare" "ordering" ("ordered" |
"unordered") |
[Definition: An ordering
mode declaration sets the ordering mode in the static context,
overriding any implementation-defined default.] This ordering mode
applies to all expressions in a module (including both the Prolog and the Query Body, if any), unless overridden by an
ordered
or unordered
expression.
The following example illustrates an ordering mode declaration:
declare ordering unordered;
If a Prolog contains more than one ordering mode declaration, a static error is raised [err:XQST0065].
| [14] | EmptyOrderDecl |
::= | "declare" "default" "order" "empty" ("greatest" |
"least") |
[Definition: An empty order
declaration sets the default order for empty sequences in
the static
context, overriding any implementation-defined default. This
declaration controls the processing of empty sequences and
NaN
values as ordering keys in an order
by
clause in a FLWOR expression.] An individual order
by
clause may override the default order for empty sequences
by specifying empty greatest
or empty
least
.
The following example illustrates an empty order declaration:
declare default order empty least;
If a Prolog contains more than one empty order declaration, a static error is raised [err:XQST0069].
Note:
It is important to distinguish an empty order
declaration from an ordering mode declaration. An
empty order declaration applies only
when an order by
clause is present, and specifies how
empty sequences are treated by the order by
clause
(unless overridden). An ordering mode declaration, on the
other hand, applies only in the absence of an order by
clause.
| [15] | CopyNamespacesDecl |
::= | "declare" "copy-namespaces" PreserveMode "," InheritMode |
| [16] | PreserveMode |
::= | "preserve" | "no-preserve" |
| [17] | InheritMode |
::= | "inherit" | "no-inherit" |
[Definition: A copy-namespaces declaration sets the value of copy-namespaces mode in the static context, overriding any implementation-defined default. Copy-namespaces mode controls the namespace bindings that are assigned when an existing element node is copied by an element constructor or document constructor.] Handling of namespace bindings by element constructors is described in 3.9.1 Direct Element Constructors.
The following example illustrates a copy-namespaces declaration:
declare copy-namespaces preserve, no-inherit;
If a Prolog contains more than one copy-namespaces declaration, a static error is raised [err:XQST0055].
| [18] | DecimalFormatDecl |
::= | "declare" (("decimal-format" EQName) | ("default" "decimal-format"))
(DFPropertyName "="
StringLiteral)* |
| [19] | DFPropertyName |
::= | "decimal-separator" | "grouping-separator" | "infinity" |
"minus-sign" | "NaN" | "percent" | "per-mille" | "zero-digit" |
"digit" | "pattern-separator" |
[Definition: A decimal
format declaration adds a decimal format to the statically known decimal formats,
which define the properties used to format numbers using the
fn:format-number()
function], as described in [XQuery and XPath Functions and Operators
3.0]. The mapping between these properties and the equivalent
fn:format-number()
properties is discussed in
statically known decimal formats,
which also specifies the defaults for each value. If a format
declares no properties, default values are used for all
properties.
It is a static error for a query prolog to contain two decimal format declarations with the same name, or to contain two default decimal format declarations [err:XQST0111]. It is a static error for a decimal format declaration to define the same property more than once [err:XQST0114]. It is a static error for a decimal format declaration to specify a value that is not valid for a given property, as described in statically known decimal formats [err:XQST0097]. It is a static error if, for any named or unnamed decimal format, the properties representing characters used in a picture string do not have distinct values [err:XQST0098]. The following properties represent characters used in a picture string: decimal-separator-sign, grouping-separator, percent-sign, per-mille-sign, zero-digit, digit-sign, and pattern-separator-sign .
The following query formats numbers using two different decimal format declarations:
declare decimal-format local:de decimal-separator = "," grouping-separator = "."; declare decimal-format local:en decimal-separator = "." grouping-separator = ","; let $numbers := (1234.567, 789, 1234567.765) for $i in $numbers return ( format-number($i, "#.###,##", "local:de"), format-number($i, "#,###.##", "local:en") )
The output of this query is:
1.234,57 1,234.57 789 789 1.234.567,76 1,234,567.76
| [21] | SchemaImport |
::= | "import" "schema" SchemaPrefix? URILiteral ("at" URILiteral ("," URILiteral)*)? |
| [22] | SchemaPrefix |
::= | ("namespace" NCName
"=") | ("default" "element" "namespace") |
[Definition: A schema import imports the element declarations, attribute declarations, and type definitions from a schema into the in-scope schema definitions. For each user-defined generalized atomic type in the schema, schema import also adds a corresponding constructor function. ] The schema to be imported is identified by its target namespace. The schema import may bind a namespace prefix to the target namespace of the imported schema, adding the (prefix, URI) pair to the statically known namespaces, or it may declare that target namespace to be the default element/type namespace. The schema import may also provide optional hints for locating the schema.
The namespace prefix specified in a schema import must not be
xml
or xmlns
[err:XQST0070], and must not be the same as
any namespace prefix bound in the same module by another schema
import, a module
import, a namespace declaration, or a
module
declaration [err:XQST0033].
The first URILiteral in a
schema import specifies the target namespace of the schema to be
imported. The URILiterals that follow the at
keyword
are optional location hints, and can be interpreted or disregarded
in an implementation-dependent way. Multiple location hints might
be used to indicate more than one possible place to look for the
schema or multiple physical resources to be assembled to form the
schema.
A schema import that specifies a zero-length string as target namespace is considered to import a schema that has no target namespace. Such a schema import must not bind a namespace prefix [err:XQST0057], but it may set the default element/type namespace to a zero-length string (representing "no namespace"), thus enabling the definitions in the imported namespace to be referenced. If the default element/type namespace is not set to "no namespace", there is no way to reference the definitions in an imported schema that has no target namespace.
It is a static
error [err:XQST0058] if more than one schema import in
the same Prolog specifies
the same target namespace. It is a static error [err:XQST0059] if the implementation is not able
to process a schema import by finding a valid schema with the
specified target namespace. It is a static error [err:XQST0035] if multiple imported schemas, or
multiple physical resources within one schema, contain definitions
for the same name in the same symbol space (for example, two
definitions for the same element name, even if the definitions are
consistent). However, it is not an error to import the schema with
target namespace http://www.w3.org/2001/XMLSchema
(predeclared prefix xs
), even though the built-in
types defined in this schema are implicitly included in the
in-scope schema
types.
It is a static error [err:XQST0012] if the set of definitions contained in all schemas imported by a Prolog do not satisfy the conditions for schema validity specified in Sections 3 and 5 of [XML Schema 1.0] or [XML Schema 1.1] Part 1--i.e., each definition must be valid, complete, and unique.
The following example imports a schema, specifying both its
target namespace and its location, and binding the prefix
soap
to the target namespace:
import schema namespace soap="http://www.w3.org/2003/05/soap-envelope" at "http://www.w3.org/2003/05/soap-envelope/";
The following example imports a schema by specifying only its target namespace, and makes it the default element/type namespace:
import schema default element namespace "http://example.org/abc";
The following example imports a schema that has no target namespace, providing a location hint, and sets the default element/type namespace to "no namespace" so that the definitions in the imported schema can be referenced:
import schema default element namespace "" at "http://example.org/xyz.xsd";
The following example imports a schema that has no target namespace and sets the default element/type namespace to "no namespace". Since no location hint is provided, it is up to the implementation to find the schema to be imported.
import schema default element namespace "";
| [23] | ModuleImport |
::= | "import" "module" ("namespace" NCName "=")? URILiteral ("at" URILiteral ("," URILiteral)*)? |
[Definition: A module import imports the public variable declarations and public function declarations from one or more library modules into the statically known function signatures and in-scope variables of the importing module.] Each module import names a target namespace and imports an implementation-defined set of modules that share this target namespace. The module import may bind a namespace prefix to the target namespace, adding the (prefix, URI) pair to the statically known namespaces, and it may provide optional hints for locating the modules to be imported.
If a module A
imports module B
, the
static context of module A
will contain the in-scope schema
definitions and statically known function
signature of module B
, and the dynamic context of
module B
will contain the variable values and named functions of
module B
, with the exception of non-public functions
and variables, and of the functions and variables not declared
directly in B
.
The following example illustrates a module import:
import module namespace gis="http://example.org/gis-functions";
If a query imports the same module via multiple paths, only one instance of the module is imported. Because only one instance of a module is imported, there is only one instance of each variable declared in a module's prolog.
A module may import its own target namespace (this is interpreted as importing an implementation-defined set of other modules that share its target namespace.)
The namespace prefix specified in a module import must not be
xml
or xmlns
[err:XQST0070], and must not be the same as
any namespace prefix bound in the same module by another module
import, a schema
import, a namespace declaration, or a
module
declaration with a different target namespace [err:XQST0033].
The first URILiteral in a
module import must be of nonzero length [err:XQST0088], and specifies the target
namespace of the modules to be imported. The URILiterals that
follow the at
keyword are optional location hints, and
can be interpreted or disregarded in an implementation-defined way.
It is a static
error [err:XQST0047] if more than one module import in
a Prolog specifies the same
target namespace. It is a static error [err:XQST0059] if the implementation is not able
to process a module import by finding a valid module definition
with the specified target namespace. It is a static error if
two or more variables declared or imported by a module have equal expanded QNames (as
defined by the eq
operator) [err:XQST0049].
Each module has its own static context. A module import imports only functions and variable declarations; it does not import other objects from the imported modules, such as in-scope schema definitions or statically known namespaces. Module imports are not transitive—that is, importing a module provides access only to function and variable declarations contained directly in the imported module. For example, if module A imports module B, and module B imports module C, module A does not have access to the functions and variables declared in module C.
A module import does not import schema definitions from the imported module. In the following query, the type geometry:triangle is not defined, even if it is known in the imported module, so the variable declaration raises an error [err:XPST0051]:
(: Error - geometry:triangle is not defined :) import module namespace geo = "http://example.org/geo-functions"; declare variable $t as geometry:triangle := geo:make-triangle(); $t
Without the type declaration for the variable, the variable declaration succeeds:
import module namespace geo = "http://example.org/geo-functions"; declare variable $t := geo:make-triangle(); $t
Importing the schema that defines the type of the variable, the variable declaration succeeds:
import schema namespace geometry = "http://example.org/geo-schema-declarations"; import module namespace geo = "http://example.org/geo-functions"; declare variable $t as geometry:triangle := geo:make-triangle(); $t
The target namespace of a module should be treated in the same way as other namespace URIs.
To maximize interoperability, query authors should use a string that is a valid absolute IRI.
Implementions must accept any string of Unicode characters. Module URIs are compared using the Unicode codepoint collation rather than any concept of semantic equivalence.
Implementations may provide mechanisms allowing the module URI to be used as input to a process that delivers the module as a resource, for example a catalog, module repository, or URI resolver. For interoperability, such mechanisms should not prevent the user from choosing an arbitrary URI for naming a module.
Similarly, implementations may perform syntactic transformations on the module URI to obtain the names of related resources, for example to implement a convention relating the name or location of compiled code to the module URI; but again, such mechanisms should not prevent the user from choosing an arbitrary module URI.
As with other namespace URIs, it is common practice to use module URIs whose scheme is "http" and whose authority part uses a DNS domain name under the control of the user.
The specifications allow, and some users might consider it good practice, for the module URI of a function library to be the same as the namespace URI of the XML vocabulary manipulated by the functions in that library.
Several different modules with the same target namespace can be used in the same query. The names of public variables and public functions must be unique within the module contexts of a query: that is, if two modules with the same module URI are used in the same query, the names of the public variables and functions in their module contexts must not overlap.
If one module contains an "import module" declaration with
the target namespace M
, then all public
variables and public functions in the contexts of
modules whose target namespace is M
must
be accessible in the importing module, regardless whether the
participation of the imported module was directly due to this
"import module" declaration.
The term "location URIs" refers to the URIs in the "at" clause of an "import module" declaration.
Products should (by default or at user option) take account of all the location URIs in an "import module" declaration, treating each location URI as a reference to a module with the specified module URI. Location URIs should be made absolute with respect to the static base URI of the module containing the "import module" declaration where they appear. The mapping from location URIs to module source code or compiled code MAY be done in any way convenient to the implementation. If possible given the product's architecture, security requirements, etc, the product should allow this to fetch the source code of the module to use the standard web mechanisms for dereferencing URIs in standard schemes such as the "http" URI scheme.
When the same absolutized location URI is used more than once, either in the same "import module" declaration or in different "import module" declarations within the same query, a single copy of the resource containing the module is loaded. When different absolutized location URIs are used, each results in a single module being loaded, unless the implementation is able to determine that the different URIs are references to the same resource. No error due to duplicate variable or functions names should arise from the same module being imported more than once, so long as the absolute location URI is the same in each case.
Implementations must report a static error if a location URI cannot be resolved after all available recovery strategies have been exhausted.
| [24] | NamespaceDecl |
::= | "declare" "namespace" NCName "=" URILiteral |
[Definition: A namespace declaration declares a namespace prefix and associates it with a namespace URI, adding the (prefix, URI) pair to the set of statically known namespaces.] The namespace declaration is in scope throughout the query in which it is declared, unless it is overridden by a namespace declaration attribute in a direct element constructor.
If the URILiteral part of a namespace declaration is a
zero-length string, any existing namespace binding for the given
prefix is removed from the statically known namespaces. This
feature provides a way to remove predeclared namespace prefixes
such as local
.
The following query illustrates a namespace declaration:
declare namespace foo = "http://example.org"; <foo:bar> Lentils </foo:bar>
In the query result, the newly created node is in the namespace
associated with the namespace URI
http://example.org
.
The namespace prefix specified in a namespace declaration must
not be xml
or xmlns
[err:XQST0070]. The
namespace URI specified in a namespace declaration must not be
http://www.w3.org/XML/1998/namespace
or
http://www.w3.org/2000/xmlns/
[err:XQST0070]. The namespace prefix
specified in a namespace declaration must not be the same as any
namespace prefix bound in the same module by a module import,
schema
import, module declaration, or another namespace
declaration [err:XQST0033].
It is a static error [err:XPST0081] if an expression contains a lexical QName with a namespace prefix that is not in the statically known namespaces.
XQuery has several predeclared namespace prefixes that are
present in the statically known namespaces before each
query is processed. These prefixes may be used without an explicit
declaration. They may be overridden by namespace
declarations in a Prolog or by namespace declaration attributes on
constructed elements (however, the prefix xml
must not
be redeclared, and no other prefix may be bound to the namespace
URI associated with the prefix xml
[err:XQST0070]). The
predeclared namespace prefixes are as follows:
xml = http://www.w3.org/XML/1998/namespace
xs = http://www.w3.org/2001/XMLSchema
xsi = http://www.w3.org/2001/XMLSchema-instance
fn = http://www.w3.org/2005/xpath-functions
local =
http://www.w3.org/2005/xquery-local-functions
(see 4.18 Function Declaration.)
Additional predeclared namespace prefixes may be added to the statically known namespaces by an implementation.
When element or attribute names are compared, they are considered identical if the local parts and namespace URIs match on a codepoint basis. Namespace prefixes need not be identical for two names to match, as illustrated by the following example:
declare namespace xx = "http://example.org"; let $i := <foo:bar xmlns:foo = "http://example.org"> <foo:bing> Lentils </foo:bing> </foo:bar> return $i/xx:bing
Although the namespace prefixes xx
and
foo
differ, both are bound to the namespace URI
http://example.org
. Since xx:bing
and
foo:bing
have the same local name and the same
namespace URI, they match. The output of the above query is as
follows.
<foo:bing xmlns:foo = "http://example.org"> Lentils </foo:bing>
| [25] | DefaultNamespaceDecl |
::= | "declare" "default" ("element" | "function") "namespace"
URILiteral |
Default namespace declarations can be used in a Prolog to facilitate the use of unprefixed QNames.
The namespace URI specified in a default namespace declaration
must not be http://www.w3.org/XML/1998/namespace
or
http://www.w3.org/2000/xmlns/
[err:XQST0070].
The following kinds of default namespace declarations are supported:
A default element/type namespace declaration declares a namespace URI that is associated with unprefixed names of elements and types. This declaration is recorded as the default element/type namespace in the static context. A Prolog may contain at most one default element/type namespace declaration [err:XQST0066]. If the URILiteral in a default element/type namespace declaration is a zero-length string, the default element/type namespace is undeclared (set to absentDM30), and unprefixed names of elements and types are considered to be in no namespace. The following example illustrates the declaration of a default namespace for elements and types:
declare default element namespace "http://example.org/names";
A default element/type namespace declaration may be overridden by a namespace declaration attribute in a direct element constructor.
If no default element/type namespace declaration is present, unprefixed element and type names are in no namespace (however, an implementation may define a different default as specified in C.1 Static Context Components.)
A default function namespace declaration declares a namespace URI that is associated with unprefixed function names in static function calls and function declarations. This declaration is recorded as the default function namespace in the static context. A Prolog may contain at most one default function namespace declaration [err:XQST0066]. If the StringLiteral in a default function namespace declaration is a zero-length string, the default function namespace is undeclared (set to absentDM30). In that case, any functions that are associated with a namespace can be called only by using an explicit namespace prefix.
If no default function namespace declaration is present, the
default function namespace is the namespace of XPath/XQuery
functions, http://www.w3.org/2005/xpath-functions
(however, an implementation may define a different default as
specified in C.1
Static Context Components.)
The following example illustrates the declaration of a default function namespace:
declare default function namespace "http://www.w3.org/2005/xpath-functions/math";
The effect of declaring a default function namespace is that all functions in the default function namespace, including implicitly-declared constructor functions, can be invoked without specifying a namespace prefix. When a static function call uses a function name with no prefix, the local name of the function must match a function (including implicitly-declared constructor functions) in the default function namespace [err:XPST0017].
Note:
Only constructor functions can be in no namespace.
Unprefixed attribute names and variable names are in no namespace.
| [26] | AnnotatedDecl |
::= | "declare" Annotation* (VarDecl | FunctionDecl) |
| [165] | InlineFunctionExpr |
::= | Annotation*
"function" "(" ParamList? ")"
("as" SequenceType)?
FunctionBody |
| [27] | Annotation |
::= | "%" EQName ("("
Literal ("," Literal)* ")")? |
XQuery uses annotations to declare properties associated with
functions (inline or declared in the prolog) and
variables. For instance, a function may be declared
%public
or %private
. The
semantics associated with these properties are described in
4.18 Function Declaration.
Annotations are (QName, value)
pairs. If the EQName
of the annotation is a lexical QName, the prefix of the QName is resolved
using the statically known namespaces; if no prefix is present,
the name is in the http://www.w3.org/2012/xquery
namespace.
Implementations may define further
annotations, whose behaviour is implementation-defined. For
instance, if the eg
prefix is bound to a namespace
associated with a particular implementation, it could define an
annotation like eg:sequential
. Implementations must
not define annotations in the following reserved namespaces;
it is an error for users to create annotations in the
following reserved namespaces [err:XQST0045]:
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2005/xpath-functions
http://www.w3.org/2005/xpath-functions/math
http://www.w3.org/2012/xquery
An annotation can provide values explicitly using a
parenthesized list of literals.
For instance, the annotation
%java:method("java.lang.Math.sin")
sets the value of
the java:method
annotation to the string value
java.lang.Math.sin
.
| [26] | AnnotatedDecl |
::= | "declare" Annotation* (VarDecl | FunctionDecl) |
| [27] | Annotation |
::= | "%" EQName ("("
Literal ("," Literal)* ")")? |
| [28] | VarDecl |
::= | "variable" "$" VarName TypeDeclaration? ((":="
VarValue) | ("external" (":="
VarDefaultValue)?)) |
| [128] | VarName |
::= | EQName |
| [167] | TypeDeclaration |
::= | "as" SequenceType |
| [29] | VarValue |
::= | ExprSingle |
| [30] | VarDefaultValue |
::= | ExprSingle |
A variable declaration adds the static type of a variable to the in-scope variables, and may also add a value for the variable to the variable values.
Note:
A variable declaration always refers to a declaration of a variable in a Prolog. The binding of a variable to a value in a query expression, such as a FLWOR expression, is known as a variable binding, and does not make the variable visible to an importing module.
During static analysis, a variable declaration causes a pair
(expanded QName N, type T)
to be added to the
in-scope variables. The expanded QName
N is the VarName
. If N is equal (as defined by the eq
operator) to the expanded QName of another variable in in-scope
variables, a static
error is raised [err:XQST0049].
All variable names declared in a library module must (when
expanded) be in the target namespace of the library module
[err:XQST0048]. A
variable declaration may use annotations to specify that the
variable is %private
or %public
(which is
the default). [Definition: A
private variable is a variable with a %private
annotation. A private variable is hidden from module import, which
can not import it into the in-scope variables of another module.]
[Definition: A public variable is a
variable without a %private
annotation. A public
variable is accessible to module import, which can import it into the
in-scope variables of another module.
Using %public
and %private
annotations in a main module is not an error, but it does not
affect module imports, since a main module cannot be
imported. It is a static error [err:XQST0116] if a variable declaration
contains both a %private
and a %public
annotation, more than one %private
annotation, or more
than one %public
annotation. ]
Variable names that have no namespace prefix are in no namespace. Variable declarations that have no namespace prefix may appear only in a main module.
Here are some examples of variable declarations:
The following declaration specifies both the type and the value
of a variable. This declaration causes the type
xs:integer
to be associated with variable
$x
in the static context, and the value
7
to be associated with variable $x
in
the dynamic
context.
declare variable $x as xs:integer := 7;
The following declaration specifies a value but not a type. The
static type of
the variable is inferred from the static type of its value. In this
case, the variable $x
has a static type of
xs:decimal
, inferred from its value which is 7.5.
declare variable $x := 7.5;
The following declaration specifies a type but not a value. The
keyword external
indicates that the value of the
variable will be provided by the external environment. At
evaluation time, if the variable $x
in the dynamic context
does not have a value of type xs:integer
, a type error is raised.
declare variable $x as xs:integer external;
The following declaration specifies neither a type nor a value.
It simply declares that the query depends on the existence of a
variable named $x
, whose type and value will be
provided by the external environment. During query analysis, the
type of $x
is considered to be item()*
.
During query evaluation, the dynamic context must include a type and a
value for $x
, and its value must be compatible with
its type.
declare variable $x external;
The following declaration, which might appear in a library module, declares a variable whose name includes a namespace prefix:
declare variable $sasl:username as xs:string :=<EMAIL_ADDRESS>This is an example of an external variable declaration that
provides a VarDefaultValue
:
declare variable $x as xs:integer external := 47;
The syntax for variable declarations allows annotations, but XQuery 3.0 does not define annotations that apply to variable declarations. An implementation can provide annotations it needs. For instance, an implemenation that supports volatile external variables might allow them to be declared using an annotation:
declare %eg:volatile variable $time as xs:time external;
The type of the declared variable is as follows:
If TypeDeclaration
is present, then the
SequenceType
in the TypeDeclaration
;
otherwise
If the Static Typing Feature is in effect and
VarValue
is present, then the static type inferred
from static analysis of the expression VarValue
;
Note:
Type inference might not be computable until after the check for circular dependencies, described below, is complete.
Otherwise, item()*
.
[Definition: If a variable declaration
includes an expression (VarValue
or
VarDefaultValue
), the expression is called an
initializing expression. The static context for an
initializing expression includes all functions, variables, and
namespaces that are declared or imported anywhere in the Prolog,
other than the variable being declared.]
During query evaluation, each variable declaration causes a pair
(expanded QName N, value V)
to be added to the
variable
values. The expanded QName N is the VarName
. The
value V is as follows:
If VarValue
is specified, then V is the result of
evaluating VarValue
as described below.
If external
is specified, then:
if a value is provided for the variable by the external environment, then V is that value. The means by which typed values of external variables are provided by the external environment is implementation-defined.
if no value is provided for the variable by the external
environment, and VarDefaultValue
is specified, then V
is the result of evaluating VarDefaultValue
as
described below.
If no value is provided for the variable by the external
environment, and VarDefaultValue
is not specified,
then a dynamic
error is raised [err:XPDY0002].
It is implementation-dependent whether this error is raised if the evaluation of the query does not reference the value of the variable.
In all cases the value V must match the type T according to the rules for SequenceType matching; otherwise a type error is raised [err:XPTY0004].
If VarValue
or VarDefaultValue
is
evaluated, the static and dynamic contexts for the evaluation
are the current module's static and dynamic context.
| [31] | ContextItemDecl |
::= | "declare" "context" "item" ("as" ItemType)? ((":=" VarValue) | ("external" (":=" VarDefaultValue)?)) |
A context item declaration allows a query to specify the static type, value, or default value for the initial context item.
Only the main module can set the value of the initial context item. In a library module, a context item declaration must be external, and specifies only the static type. Specifying a VarValue or VarDefaultValue for a context item declaration in a library module is a static error [err:XQST0113].
In every module that does not contain a context item declaration, the effect is as if the declaration
declare context item as item() external;
appeared in that module.
During static analysis, the context item declaration has the
effect of setting the context item static type T
in
the static context. The context item static type is set to
ItemType
if specified, or to item()
otherwise.
If a module contains more than one context item declaration, a static error is raised [err:XQST0099].
The static context for an initializing expression includes all functions, variables, and namespaces that are declared or imported anywhere in the Prolog.
During query evaluation, a singleton 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, selecting the context item for the
singleton focus as follows:
If VarValue
is specified, then the result of
evaluating VarValue
as described below.
If external
is specified, then:
if a value is provided for the context item by the external environment, then that value.
The means by which an external value is provided by the external environment is implementation-defined.
if no value is provided for the context item by the external
environment, and VarDefaultValue
is specified,
the static and dynamic contexts for the evaluation are the
current module's static and dynamic context.
In all cases where the context item has a value, that value must
match the type T
according to the rules for
SequenceType matching; otherwise a type error is raised [err:XPTY0004]. If more than
one module contains a context item declaration, the context item
must match the type declared in each one.
Here are some examples of context item declarations.
Declare the type of the context item:
declare namespace env="http://www.w3.org/2003/05/soap-envelope"; declare context item as element(env:Envelope) external;
Declare a default context item, 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 item as element(sys:log) external := doc("/var/xlogs/sysevent.xml")/sys:log;
In addition to the built-in functions described in [XQuery and XPath Functions and Operators 3.0], XQuery allows users to declare functions of their own. A function declaration specifies the name of the function, the names and datatypes of the parameters, and the datatype of the result. All datatypes are specified using the syntax described in 2.5 Types. A function declaration causes the declared function to be added to the statically known function signatures and the named functions of the module in which it appears.
| [26] | AnnotatedDecl |
::= | "declare" Annotation* (VarDecl | FunctionDecl) |
| [27] | Annotation |
::= | "%" EQName ("("
Literal ("," Literal)* ")")? |
| [32] | FunctionDecl |
::= | "function" EQName "("
ParamList? ")" ("as" SequenceType)? (FunctionBody |
"external") |
| [33] | ParamList |
::= | Param ("," Param)* |
| [34] | Param |
::= | "$" EQName TypeDeclaration? |
| [35] | FunctionBody |
::= | EnclosedExpr |
| [167] | TypeDeclaration |
::= | "as" SequenceType |
A function declaration specifies whether a function is user-defined or external.
[Definition: User defined functions are functions that contain a function body, which provides the implementation of the function as an XQuery expression.] The static context for a function body includes all functions, variables, and namespaces that are declared or imported anywhere in the Prolog, including the function being declared. Its in-scope variables component also includes the parameters of the function being declared. However, its context item static type component is absentDM30.
[Definition: External functions are
functions that are implemented outside the query environment.] For
example, an XQuery implementation might provide a set of external
functions in addition to the core function library described in
[XQuery and XPath Functions and
Operators 3.0]. External functions are identified by the
keyword external
. The purpose of a function
declaration for an external function is to declare the datatypes of
the function parameters and result, for use in type checking of the
query that contains or imports the function declaration.
A function declaration may use the %private
or %public
annotations to specify that a function is
public or private; if neither of these annotations is used, the
function is public. [Definition: A
private function is a function with a %private
annotation. A private function is hidden from module import, which
can not import it into the statically known function
signatures of another module. ] [Definition: A
public function is a function without a
%private
annotation. A public function is
accessible to module import, which can import it into the
statically known function
signatures of another module. ] Using
%public
and %private
annotations in a
main module is not an error, but it does not affect module imports,
since a main module cannot be imported. It is a static error [err:XQST0106] if a
function declaration contains both a %private
and a
%public
annotation, more than one
%private
annotation, or more than one
%public
annotation.
An XQuery implementation may provide a facility whereby external
functions can be implemented using a host programming language, but
it is not required to do so. If such a facility is provided, the
protocols by which parameters are passed to an external function,
and the result of the function is returned to the invoking query,
are implementation-defined. An XQuery
implementation may augment the type system of [XQuery and XPath Data Model (XDM) 3.0]
with additional types that are designed to facilitate exchange of
data with host programming languages, or it may provide mechanisms
for the user to define such types. For example, a type might be
provided that encapsulates an object returned by an external
function, such as an SQL database connection. These additional
types, if defined, are considered to be derived by restriction from
xs:anyAtomicType
.
An implementation can define annotations, in its own namespace, to support functionality beyond the scope of this specification. For instance, an implementation that supports external Java functions might use an annotation to associate a Java function with an XQuery external function:
declare %java:method("java.lang.StrictMath.copySign") function smath:copySign($magnitude, $sign) external;
Every declared function must be in a namespace; that is, every declared function name must (when expanded) have a non-null namespace URI [err:XQST0060]. If the function name in a function declaration has no namespace prefix, it is considered to be in the default function namespace. Every function name declared in a library module must (when expanded) be in the target namespace of the library module [err:XQST0048]. It is a static error [err:XQST0045] if the function name in a function declaration (when expanded) is in any of the following namespaces:
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2005/xpath-functions
http://www.w3.org/2005/xpath-functions/math
http://www.w3.org/2012/xquery
In order to allow main modules to declare functions for local
use within the module without defining a new namespace, XQuery
predefines the namespace prefix local
to the namespace
http://www.w3.org/2005/xquery-local-functions
. It is
suggested (but not required) that this namespace be used for
defining local functions.
If a function parameter is declared using a name but no type,
its default type is item()*
. If the result type is
omitted from a function declaration, its default result type is
item()*
.
The parameters of a function declaration are considered to be variables whose scope is the function body. It is an static error [err:XQST0039] for a function declaration to have more than one parameter with the same name. The type of a function parameter can be any type that can be expressed as a sequence type.
A FunctionDecl
defines a function with the
following properties:
name: The EQName
of the
FunctionDecl
, expanded (if necessary) using the
statically known namespaces and
default
function namespace of the module's static context.
parameter names: The EQName
s in the
ParamList
, expanded (if necessary) using the statically known namespaces of the
module's static context.
signature: A FunctionTest
built from the
SequenceType
s (explicit or implicit) in the
FunctionDecl
and its ParamList
, and from
any Annotation
s preceding the
FunctionDecl
.
implementation: If the function is declared external,
this property is implementation-dependent. Otherwise, this property
is the FunctionDecl
's FunctionBody
.
nonlocal variable bindings: Empty.
The following example illustrates the declaration and use of a
local function that accepts a sequence of employee
elements, summarizes them by department, and returns a sequence of
dept
elements.
Using a function, prepare a summary of employees that are located in Denver.
declare function local:summary($emps as element(employee)*) as element(dept)* { for $d in fn:distinct-values($emps/deptno) let $e := $emps[deptno = $d] return <dept> <deptno>{$d}</deptno> <headcount> {fn:count($e)} </headcount> <payroll> {fn:sum($e/salary)} </payroll> </dept> }; local:summary(fn:doc("acme_corp.xml")//employee[location = "Denver"])
A function declaration may be recursive—that is, it may
reference itself. Mutually recursive functions, whose bodies
reference each other, are also allowed. The following example
declares a recursive function that computes the maximum depth of a
node hierarchy, and calls the function to find the maximum depth of
a particular document. The function local:depth
calls
the built-in functions empty
and max
,
which are in the default function namespace.
Find the maximum depth of the document named
partlist.xml
.
declare function local:depth($e as node()) as xs:integer { (: A node with no children has depth 1 :) (: Otherwise, add 1 to max depth of children :) if (fn:empty($e/*)) then 1 else fn:max(for $c in $e/* return local:depth($c)) + 1 }; local:depth(fn:doc("partlist.xml"))
[Definition: An option declaration declares an option that affects the behavior of a particular implementation. Each option consists of an identifying EQName and a StringLiteral.]
| [37] | OptionDecl |
::= | "declare" "option" EQName StringLiteral |
Typically, a particular option will be recognized by some implementations and not by others. The syntax is designed so that option declarations can be successfully parsed by all implementations.
If the EQName of an option is a lexical QName with a prefix, it must resolve to a namespace URI and local name, using the statically known namespaces [err:XPST0081].
If the EQName of an option does not have a prefix, the expanded QName is in
the http://www.w3.org/2012/xquery
namespace. In option
declarations in this namespace, unprefixed QNames in the string
literal are also in the http://www.w3.org/2012/xquery
namespace. Thus, in the following example, the option name
require-feature
is in the
http://www.w3.org/2012/xquery
namespace because it has
no prefix, and is therefore defined in the default namespace for
the names of option declarations. The name "schema-aware" is in the
same namespace because it has no prefix and the option name is in
the http://www.w3.org/2012/xquery
namespace.
declare option require-feature "schema-aware"
Each implementation recognizes an implementation-defined set of namespace URIs used in option names. If the namespace part of an option declaration's name is not recognized, the option declaration is ignored.
Otherwise, the effect of the option declaration, including its error behavior, is implementation-defined. For example, if the local part of the QName is not recognized, or if the StringLiteral does not conform to the rules defined by the implementation for the particular option declaration, the implementation may choose whether to raise an error, ignore the option declaration, or take some other action.
Implementations may impose rules on where particular option declarations may appear relative to variable declarations and function declarations, and the interpretation of an option declaration may depend on its position.
An option declaration must not be used to change the syntax accepted by the processor, or to suppress the detection of static errors. However, it may be used without restriction to modify the semantics of the query. The scope of the option declaration is implementation-defined—for example, an option declaration might apply to the whole query, to the current module, or to the immediately following function declaration.
The following examples illustrate several possible uses for option declarations:
This option declaration might be used to specify how comments in
source documents returned by the fn:doc()
function
should be handled:
declare option exq:strip-comments "true";
This option declaration might be used to associate a namespace used in function names with a Java class:
declare namespace smath = "http://example.org/MathLibrary"; declare option exq:java-class "smath = java.lang.StrictMath";
The require-feature
or
prohibit-feature
options, which are defined in the
http://www.w3.org/2012/xquery
namespace, are used to
require or prohibit features in a module.
[Definition: A named feature is a feature
that is associated with a name.] The name of a named feature is
represented as a lexical QName [err:XQST0122], and any prefixes used in this
QName must be defined in the statically known namespaces [err:XPST0081]. QNames
without prefixes are in the
http://www.w3.org/2012/xquery
namespace.
A require-feature
option declaration provides a
list of named
features that must be enabled for the module in which the
option declaration occurs; if any declaration requires a feature
that the implementation does not support, a static error [err:XQST0120] is raised. A
prohibit-feature
option declaration provides a list of
named
features that must not be enabled in the module in which the
option declaration occurs; if any of these QNames corresponds to a
feature that the implementation supports, it must disable that
feature, acting as though the feature were not implemented, or
raise a static error [err:XQST0131].
The features required or prohibited in one module of a query are independent of any features required or prohibited in other modules of the same query.
It is a static error [err:XQST0127] if a given feature is both required and prohibited, directly or indirectly, in a module.
Note:
This error can occur either because a feature is required or prohibited directly, or indirectly as a result of requiring or prohibiting another feature.
In XQuery 3.0, the following feature names may be used in
require-feature
or prohibit-feature
option declarations; they are all defined in the
http://www.w3.org/2012/xquery
namespace.
The name schema-aware
corresponds to the feature
defined in 5.2.3 Schema Aware
Feature.
The name static-typing
corresponds to the feature
defined in 5.2.4 Static
Typing Feature.
The name module
corresponds to the feature defined
in 5.2.5 Module Feature.
The module
feature can only be required or prohibited
in a main module, not in a library module [err:XQST0132].
The name higher-order-function
corresponds to the
feature defined in 5.2.7 Higher-Order Function
Feature.
The name all-extensions
corresponds to all
named
features not defined in the
http://www.w3.org/2012/xquery
namespace. When it
appears in a prohibit-feature
declaration, an
implementation must disable all such features, and a static error
is raised if such a feature is also required, directly or
indirectly [err:XQST0127]. If all-extensions
appears in a require-feature
option declaration, a
static error is
raised [err:XQST0126].
The name all-optional-features
corresponds to the
set of all named
features that correspond to features listed in 5.2 Optional Features.
If all-optional-features
appears in a
require-feature
option declaration, all optional
features that are not prohibited (implicitly or explicitly) must be
enabled. If all-optional-features
appears in a
prohibit-feature
option declaration, all optional
features that are not required (implicitly or explicitly) must be
disabled.
Note:
5.2.6 Serialization Feature does not have a feature name, and cannot be required or prohibited in a module. It is nevertheless an optional feature.
All implementations must recognize the feature names in the above list.
Implementations and XQuery-related specifications that extend
XQuery should define a named feature for each extension. Features
that are not defined by the W3C XML Query Working Group must not be
in the http://www.w3.org/2012/xquery
namespace. If an
implementation encounters a feature name that it does not recognize
in a require-feature
option, it must raise an error
[err:XQST0123]. If
an implementation encounters a feature name that it does not
recognize in a prohibit-feature
option, that feature
is ignored; it is a static error [err:XQST0128] if a feature name that an
implementation supports appears in a prohibit-feature
option declaration and the implementation is unable to disable the
feature. If an implementation adds feature names in a given
namespace, an implementation must define the name
all-optional-features
in that namespace; for the
namespace associated with the prefix vend
, if
vend:all-optional-features
appears in a
require-feature
option declaration, all optional
features in the namespace associated with the prefix
vend
that are not explicitly prohibited must be
enabled.
Features can be organized in hierarchies. [Definition: For two features A
and D in the same namespace, if the local name of
feature A contains the local name of feature
D as a leading substring, using the Unicode codepoint
collation
(http://www.w3.org/2005/xpath-functions/collation/codepoint
),
then feature A contains feature
D.] For instance, a vendor might provide a feature
called gis:geography
, which contains subfeatures like
gis:geography-terrain
,
gis:geography-roads
, and
gis:geography-soil
. If a feature is required, an
implementation must enable both that feature and all features that
contain it.
Within any given hierarchy, feature names that end with the
string "all-optional-features"
can be used to require
or prohibit optional features. If A is the name of a
feature, then "
A
-all-optional-features"
refers to the set of all
features
contained in A.
The following declarations require schema validation and schema import and higher order functions, but prohibit static typing. An implementation that does not support schema validation, schema import, or higher order functions must raise an error [err:XQST0120]. An implementation that supports static typing must disable static typing or raise an error [err:XQST0131].
declare option require-feature "schema-aware higher-order-function"; declare option prohibit-feature "static-typing";
The following declaration requires a vendor-defined extension
named random-result
. A query implementation that does
not recognize this extension may simply ignore this declaration,
since it does not implement the feature.
declare namespace rand = "http://random.example.com/xquery"; declare option require-feature "rand:random-result";
The following declaration prohibits all vendor extensions:
declare option prohibit-feature "all-extensions";
The following declaration requires all optional features defined in the XQuery specification:
declare option require-feature "all-optional-features";
The following declaration, based on the GIS example from the
previous paragraph, requires gis:geography-terrain
,
thus implicitly requiring gis:geography
, and prohibits
all other optional features:
declare namespace gis="http://geography.example.com/gis"; declare option require-feature "gis:geography-terrain"; declare option prohibit-feature "gis:all-optional-features";
This section defines the conformance criteria for an XQuery processor. In this section, the following terms are used to indicate the requirement levels defined in [RFC 2119]. [Definition: MUST means that the item is an absolute requirement of the specification.] [Definition: MUST NOT means that the item is an absolute prohibition of the specification.] [Definition: MAY means that an item is truly optional.] [Definition: SHOULD means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.]
An XQuery processor that claims to conform to this specification MUST include a claim of Minimal Conformance as defined in 5.1 Minimal Conformance. In addition to a claim of Minimal Conformance, it MAY claim conformance to one or more optional features defined in 5.2 Optional Features.
An implementation that claims Minimal Conformance to this specification MUST provide all of the following items:
An implementation of everything specified in this document except those features specified in 5.2 Optional Features to be optional. If an implementation does not provide a given optional feature, it MUST implement any requirements specified in 5.2 Optional Features for implementations that do not provide that feature.
A definition of every item specified to be implementation-defined, unless that item is part of an optional feature that is not provided by the implementation. A list of implementation-defined items can be found in D Implementation-Defined Items.
Note:
Implementations are not required to define items specified to be implementation-dependent.
An implementation of [XQuery and XPath Data Model (XDM) 3.0], as specified in 5.3 Data Model Conformance, and a definition of every item specified to be implementation-defined, unless that item is part of an optional feature that is not provided by the implementation.
An implementation of all functions defined in [XQuery and XPath Functions and Operators 3.0], and a definition of every item specified to be implementation-defined, unless that function or item is part of an optional feature that is not provided by the implementation.
The features discussed in this section are optional. An implementation MAY claim conformance to one or more of these features.
The description of each feature mentions any errors that may occur if a query relies on a feature that is not present.
[Definition: The Schema Aware
Feature permits the query Prolog to contain a schema import, and
permits a query to contain a validate
expression (see
3.18 Validate Expressions). ]
If an XQuery implementation does not provide the
Schema Aware Feature, it MUST
raise a static error [err:XQST0009] if it encounters a schema import,
and it MUST raise a static error
[err:XQST0075] if
it encounters a validate
expression.
[Definition: The Static Typing Feature requires implementations to report all type errors during the static analysis phase.]
If an implementation provides the Static Typing Feature, then it MUST raise an error during static analysis whenever the inferred static type of an expression is not subsumed by the required type for the context in which it appears.
If an implementation does not provide the Static Typing Feature, then it MAY report type errors during the static analysis phase only in cases where the inferred static type and the required type have an empty intersection (that is, where evaluation of the expression is guaranteed to fail). It MAY defer some or all type checking until the dynamic evaluation phase.
[Definition: The Module Feature allows a query Prolog to contain a Module Import and allows library modules to be created.]
An implementation that does not provide the Module Feature MUST raise a static error [err:XQST0016] if it encounters a module declaration or a module import. Since a module declaration is required in a library module, the Module Feature is required in order to create a library module.
Note:
In the absence of the Module Feature, each query consists of a single main module.
[Definition: The Serialization Feature provides means for serializing the result of a query as specified in 2.2.4 Serialization.] A conforming XQuery implementation that provides the Serialization Feature MUST conform to 2.2.4 Serialization. An implementation MAY provide other forms of serialization, which do not conform to the Serialization Feature, and are beyond the scope of this specification.
The means by which serialization is invoked is implementation-defined.
If an error is raised during the serialization process as specified in [XSLT and XQuery Serialization 3.0], an implementation MUST report the error to the calling environment.
An implementation that does not
provide the Serialization Feature MUST NOT raise errors when reading an output
declaration, and MUST
implement fn:serialize
; it MAY, however, raise an error when
fn:serialize
is invoked, as specified in Section
14.9.3 fn:serialize FO30.
an implementation that does not provide
the Serialization Feature MAY
provide results of a query using a vendor-defined
serialization.
Note:
Some implementations return query results without serialization. For instance, an implementation might provide results via an XML API or a binary representation such as a persistent DOM.
[Definition: The Higher Order Function Feature allows an expression to evaluate to a function, and allows dynamic function calls.]
An implementation that does not provide the Higher-Order Function Feature MUST raise a static error [err:XQST0129] if it encounters a FunctionTest, dynamic function call, named function reference, inline function expression, or partial function application. Such an implementation MAY raise a type error [err:XPTY0004] if an expression evaluates to a sequence that contains a function.
If an implementation provides the Higher-Order Function Feature,
then it must provide fn:function-lookup
,
fn:function-name
, fn:function-arity
,
fn:map
, fn:filter
,
fn:fold-left
, fn:fold-right
, and
fn:map-pairs
. If an implementation does not provide
the Higher Order Function Feature, a static error is raised [err:XPST0017] if any of
these functions is present in a query.
All XQuery implementations process data represented in the data model as specified in [XQuery and XPath Data Model (XDM) 3.0]. The data model specification relies on languages such as XQuery to specify conformance criteria for the data model in their respective environments, and suggests that the following issues should be considered:
Support for normative construction from an infoset. An implementation MAY choose to claim conformance to Section 3.2 Construction from an Infoset DM30, which defines a normative way to construct an XDM instance from an XML document that is merely well-formed or is governed by a DTD.
Support for normative construction from a PSVI. An implementation MAY choose to claim conformance to Section 3.3 Construction from a PSVI DM30, which defines a normative way to construct an XDM instance from an XML document that is governed by a W3C XML Schema.
At the time of writing there is no published version of XML
Schema that references the XML 1.1 specifications. This means that
datatypes such as xs:NCName
and xs:ID
are
constrained by the XML 1.0 rules. It is recommended that an XQuery
1.0 processor should implement the rules defined by later versions
of XML Schema as they become available.
Support for versions of XML and XSD. As stated in [XQuery and XPath Data Model (XDM) 3.0], it is recommended (but not required) that the definitions of primitives such as strings, characters, and names should be taken from the latest applicable version of the base specifications in which they are defined; it is implementation-defined which definitions are used in cases where these differ.
Note:
For suggestions on processing XML 1.1 documents with XSD 1.0, see [XML 1.1 and Schema 1.0].
Ranges of data values. In XQuery, the following limits are implementation-defined:
For the xs:decimal
type, the maximum number of
decimal digits (totalDigits
facet) (must be at least
18).
For the types xs:date
, xs:time
,
xs:dateTime
, xs:gYear
, and
xs:gYearMonth
: the maximum value of the year component
and the maximum number of fractional second digits (must be at
least 3).
For the xs:duration type
: the maximum absolute
values of the years, months, days, hours, minutes, and seconds
components.
For the xs:yearMonthDuration
type: the maximum
absolute value, expressed as an integer number of months.
For the xs:dayTimeDuration
type: the maximum
absolute value, expressed as a decimal number of seconds.
For the types xs:string
, xs:hexBinary
,
xs:base64Binary
, xs:QName
,
xs:anyURI
, xs:NOTATION
, and types derived
from them: limitations (if any) imposed by the implementation on
lengths of values.
The limits listed above need not be fixed, but may depend on
environmental factors such as system resources. For example, the
length of a value of type xs:string
may be limited by
available memory.
Any syntactic extensions to XQuery are implementation-defined. The effect of syntactic extensions, including their error behavior, is implementation-defined. Syntactic extensions may be used without restriction to modify the semantics of a XQuery expression.
The grammar of XQuery 3.0 uses the same simple Extended Backus-Naur Form (EBNF) notation as [XML 1.0] with the following minor differences.
All named symbols have a name that begins with an uppercase letter.
It adds a notation for referring to productions in external specs.
Comments or extra-grammatical constraints on grammar productions are between '/*' and '*/' symbols.
A 'xgc:' prefix is an extra-grammatical constraint, the details of which are explained in A.1.2 Extra-grammatical Constraints
A 'ws:' prefix explains the whitespace rules for the production, the details of which are explained in A.2.4 Whitespace Rules
A 'gn:' prefix means a 'Grammar Note', and is meant as a clarification for parsing rules, and is explained in A.1.3 Grammar Notes. These notes are not normative.
The terminal symbols for this grammar include the quoted strings used in the production rules below, and the terminal symbols defined in section A.2.1 Terminal Symbols.
The EBNF notation is described in more detail in A.1.1 Notation.
To increase readability, the EBNF in the main body of this document omits some of these notational features. This appendix is the normative version of the EBNF.
The following definitions will be helpful in defining precisely this exposition.
[Definition: Each rule in the grammar defines one symbol, using the following format:
symbol ::= expression
]
[Definition: A terminal is a symbol or string or pattern that can appear in the right-hand side of a rule, but never appears on the left-hand side in the main grammar, although it may appear on the left-hand side of a rule in the grammar for terminals.] The following constructs are used to match strings of one or more characters in a terminal:
matches any Char with a value in the range(s) indicated (inclusive).
matches any Char with a value among the characters enumerated.
matches any Char with a value not among the characters given.
matches the sequence of characters that appear inside the double quotes.
matches the sequence of characters that appear inside the single quotes.
matches any string matched by the production defined in the external specification as per the provided reference.
Patterns (including the above constructs) can be combined with grammatical operators to form more complex patterns, matching more complex sets of character strings. In the examples that follow, A and B represent (sub-)patterns.
A
is treated as a unit and may be combined as
described in this list.
matches A
or nothing; optional A
.
matches A
followed by B
. This operator
has higher precedence than alternation; thus A B | C D
is identical to (A B) | (C D)
.
matches A
or B
but not both.
matches any string that matches A
but does not
match B
.
matches one or more occurrences of A
. Concatenation
has higher precedence than alternation; thus A+ | B+
is identical to (A+) | (B+)
.
matches zero or more occurrences of A
.
Concatenation has higher precedence than alternation; thus A*
| B*
is identical to (A*) | (B*)
This section contains constraints on the EBNF productions, which are required to parse syntactically valid sentences. The notes below are referenced from the right side of the production, with the notation: /* xgc: <id> */.
Constraint: leading-lone-slash
A single slash may appear either as a complete path expression
or as the first part of a path expression in which it is followed
by a RelativePathExpr.
In some cases, the next token after the slash is insufficient to
allow a parser to distinguish these two possibilities: the
*
token and keywords like union
could be
either an operator or a NameTest , and
the <
token could be either an operator or the
start of a DirectConstructor .
For example, without lookahead the first part of the expression
/ * 5
is easily taken to be a complete expression,
/ *
, which has a very different interpretation (the
child nodes of /
).
Therefore to reduce the need for lookahead, if the token immediately following a slash can form the start of a RelativePathExpr, then the slash must be the beginning of a PathExpr, not the entirety of it.
A single slash may be used as the left-hand argument of an
operator by parenthesizing it: (/) * 5
. The expression
5 * /
, on the other hand, is syntactically valid
without parentheses.
The version of XML and XML Names (e.g. [XML
1.0] and [XML Names], or [XML 1.1] and [XML Names
1.1]) is implementation-defined. It is
recommended that the latest applicable version be used (even if it
is published later than this specification). The EBNF in this
specification links only to the 1.0 versions. Note also that these
external productions follow the whitespace rules of their
respective specifications, and not the rules of this specification,
in particular A.2.4.1
Default Whitespace Handling. Thus prefix :
localname
is not a syntactically valid lexical QName for purposes of
this specification, just as it is not permitted in a XML document.
Also, comments are not permissible on either side of the colon.
Also extra-grammatical constraints such as well-formedness
constraints must be taken into account.
XML 1.0 and XML 1.1 differ in their handling of C0 control characters (specifically #x1 through #x1F, excluding #x9, #xA, and #xD) and C1 control characters (#x7F through #x9F). In XML 1.0, these C0 characters are prohibited, and the C1 characters are permitted. In XML 1.1, both sets of control characters are permitted, but only if written as character references. It is RECOMMENDED that implementations should follow the XML 1.1 rules in this respect; however, for backwards compatibility with XQuery 1.0 , implementations MAY allow C1 control characters to be used directly.
Note:
Direct use of C1 control characters often suggests a character encoding error, such as using encoding CP-1252 and mislabeling it as iso-8859-1.
Constraint: reserved-function-names
Unprefixed function names spelled the same way as language
keywords could make the language harder to recognize. For instance,
if(foo)
could be taken either as a FunctionCall or as the beginning
of an IfExpr. Therefore, an
unprefixed function name must not be any of the names in A.3 Reserved Function Names.
A function named "if" can be called by binding its namespace to a prefix and using the prefixed form: "library:if(foo)" instead of "if(foo)".
Constraint: occurrence-indicators
As written, the grammar in A XQuery 3.0 Grammar is ambiguous for some forms using the '+' and '*' Kleene operators. The ambiguity is resolved as follows: these operators are tightly bound to the SequenceType expression, and have higher precedence than other uses of these symbols. Any occurrence of '+' and '*', as well as '?', following a sequence type is assumed to be an occurrence indicator, which binds to the last ItemType in the SequenceType.
Thus, 4 treat as item() + - 5
must be interpreted
as (4 treat as item()+) - 5
, taking the '+' as an
OccurrenceIndicator and the '-' as a subtraction operator. To force
the interpretation of "+" as an addition operator (and the
corresponding interpretation of the "-" as a unary minus),
parentheses may be used: the form (4 treat as item()) +
-5
surrounds the SequenceType expression with
parentheses and leads to the desired interpretation.
function () as xs:string *
is interpreted as
function () as (xs:string *)
, not as (function
() as xs:string) *
. Parentheses can be used as shown to
force the latter interpretation.
This rule has as a consequence that certain forms which would otherwise be syntactically valid and unambiguous are not recognized: in "4 treat as item() + 5", the "+" is taken as an OccurrenceIndicator, and not as an operator, which means this is not a syntactically valid expression.
This section contains general notes on the EBNF productions, which may be helpful in understanding how to interpret and implement the EBNF. These notes are not normative. The notes below are referenced from the right side of the production, with the notation: /* gn: <id> */.
Note:
Look-ahead is required to distinguish FunctionCall from a EQName or
keyword followed by a Pragma or Comment. For example: address (:
this may be empty :)
may be mistaken for a call to a
function named "address" unless this lookahead is employed. Another
example is for (: whom the bell :) $tolls in 3 return
$tolls
, where the keyword "for" must not be mistaken for a
function name.
Comments are allowed everywhere that ignorable whitespace is allowed, and the Comment symbol does not explicitly appear on the right-hand side of the grammar (except in its own production). See A.2.4.1 Default Whitespace Handling. Note that comments are not allowed in direct constructor content, though they are allowed in nested EnclosedExprs.
A comment can contain nested comments, as long as all "(:" and ":)" patterns are balanced, no matter where they occur within the outer comment.
Note:
Lexical analysis may typically handle nested comments by incrementing a counter for each "(:" pattern, and decrementing the counter for each ":)" pattern. The comment does not terminate until the counter is back to zero.
Some illustrative examples:
(: commenting out a (: comment :) may be confusing, but
often helpful :)
is a syntactically valid Comment, since
balanced nesting of comments is allowed.
"this is just a string :)"
is a syntactically valid
expression. However, (: "this is just a string :)" :)
will cause a syntax error. Likewise, "this is another string
(:"
is a syntactically valid expression, but (: "this
is another string (:" :)
will cause a syntax error. It is a
limitation of nested comments that literal content can cause
unbalanced nesting of comments.
for (: set up loop :) $i in $x return $i
is
syntactically valid, ignoring the comment.
5 instance (: strange place for a comment :) of
xs:integer
is also syntactically valid.
<eg (: an example:)>{$i//title}</eg>
is
not syntactically valid.
<eg> (: an example:) </eg>
is
syntactically valid, but the characters that look like a comment
are in fact literal element content.
The terminal symbols assumed by the grammar above are described in this section.
Quoted strings appearing in production rules are terminal symbols.
Other terminal symbols are defined in A.2.1 Terminal Symbols.
Some productions are defined by reference to the XML and XML Names specifications (e.g. [XML 1.0] and [XML Names], or [XML 1.1] and [XML Names 1.1] . It is implementation-defined which version of these specifications is used; it is recommended that the latest applicable version be used (even if it is published later than this specification).
When tokenizing, the longest possible match that is valid in the current context is used.
All keywords are case sensitive. Keywords are not reserved—that is, any lexical QName may duplicate a keyword except as noted in A.3 Reserved Function Names.
The following symbols are used only in the definition of terminal symbols; they are not terminal symbols in the grammar of A.1 EBNF.
| [216] | Digits |
::= | [0-9]+ |
| [217] | CommentContents |
::= | (Char+ - (Char* ('(:' |
':)') Char*)) |
XQuery 3.0 expressions consist of terminal symbols and symbol separators.
Terminal symbols that are not used exclusively in /* ws: explicit */ productions are of two kinds: delimiting and non-delimiting.
[Definition: The delimiting terminal symbols are: S, "!", "!=", StringLiteral, "#", "#)", "$", "%", "(", "(#", ")", "*", "+", (comma), "-", "-->", (dot), "..", "/", "//", "/>", (colon), "::", ":=", (semi-colon), "<", "<!--", "<![CDATA[", "</", "<<", "<=", "<?", "=", ">", ">=", ">>", "?", "?>", "@", BracedURILiteral, "[", "]", "]]>", "{", "|", "||", "}" ]
[Definition: The non-delimiting terminal symbols are: IntegerLiteral, URIQualifiedName, NCName, DecimalLiteral, DoubleLiteral, QName, "NaN", "allowing", "ancestor", "ancestor-or-self", "and", "as", "ascending", "at", "attribute", "base-uri", "boundary-space", "by", "case", "cast", "castable", "catch", "child", "collation", "comment", "construction", "context", "copy-namespaces", "count", "decimal-format", "decimal-separator", "declare", "default", "descendant", "descendant-or-self", "descending", "digit", "div", "document", "document-node", "element", "else", "empty", "empty-sequence", "encoding", "end", "eq", "every", "except", "external", "following", "following-sibling", "for", "function", "ge", "greatest", "group", "grouping-separator", "gt", "idiv", "if", "import", "in", "infinity", "inherit", "instance", "intersect", "is", "item", "lax", "le", "least", "let", "lt", "minus-sign", "mod", "module", "namespace", "namespace-node", "ne", "next", "no-inherit", "no-preserve", "node", "of", "only", "option", "or", "order", "ordered", "ordering", "parent", "pattern-separator", "per-mille", "percent", "preceding", "preceding-sibling", "preserve", "previous", "processing-instruction", "return", "satisfies", "schema", "schema-attribute", "schema-element", "self", "sliding", "some", "stable", "start", "strict", "strip", "switch", "text", "then", "to", "treat", "try", "tumbling", "type", "typeswitch", "union", "unordered", "validate", "variable", "version", "when", "where", "window", "xquery", "zero-digit" ]
[Definition: Whitespace and Comments function as symbol separators. For the most part, they are not mentioned in the grammar, and may occur between any two terminal symbols mentioned in the grammar, except where that is forbidden by the /* ws: explicit */ annotation in the EBNF, or by the /* xgc: xml-version */ annotation.]
It is customary to separate consecutive terminal symbols by whitespace and Comments, but this is required only when otherwise two non-delimiting symbols would be adjacent to each other. There are two exceptions to this, that of "." and "-", which do require a symbol separator if they follow a QName or NCName. Also, "." requires a separator if it precedes or follows a numeric literal.
Prior to parsing, the XQuery 3.0 processor must normalize all line breaks. The rules for line breaking follow the rules of [XML 1.0] or [XML 1.1]. It is implementation-defined which version is used.
For [XML 1.0] processing, all of the following must be translated to a single #xA character:
the two-character sequence #xD #xA
any #xD character that is not immediately followed by #xA.
For [XML 1.1] processing, all of the following must be translated to a single #xA character:
the two-character sequence #xD #xA
the two-character sequence #xD #x85
the single character #x85
the single character #x2028
any #xD character that is not immediately followed by #xA or #x85.
The characters #x85 and #x2028 cannot be reliably recognized and translated until the VersionDecl declaration (if present) has been read.
[Definition: A whitespace character is any of the characters defined by [http://www.w3.org/TR/REC-xml/#NT-S].]
[Definition: Ignorable whitespace consists of any whitespace characters that may occur between terminals, unless these characters occur in the context of a production marked with a ws:explicit annotation, in which case they can occur only where explicitly specified (see A.2.4.2 Explicit Whitespace Handling).] Ignorable whitespace characters are not significant to the semantics of an expression. Whitespace is allowed before the first terminal and after the last terminal of a module. Whitespace is allowed between any two terminals. Comments may also act as "whitespace" to prevent two adjacent terminals from being recognized as one. Some illustrative examples are as follows:
foo- foo
results in a syntax error. "foo-" would be
recognized as a QName.
foo -foo
is syntactically equivalent to foo -
foo
, two QNames separated by a subtraction operator.
foo(: This is a comment :)- foo
is syntactically
equivalent to foo - foo
. This is because the comment
prevents the two adjacent terminals from being recognized as
one.
foo-foo
is syntactically equivalent to single
QName. This is because "-" is a valid character in a QName. When
used as an operator after the characters of a name, the "-" must be
separated from the name, e.g. by using whitespace or
parentheses.
10div 3
results in a syntax error.
10 div3
also results in a syntax error.
10div3
also results in a syntax error.
Explicit whitespace notation is specified with the EBNF productions, when it is different from the default rules, using the notation shown below. This notation is not inherited. In other words, if an EBNF rule is marked as /* ws: explicit */, the notation does not automatically apply to all the 'child' EBNF productions of that rule.
/* ws: explicit */ means that the EBNF notation explicitly
notates, with S
or otherwise, where whitespace characters are
allowed. In productions with the /* ws: explicit */ annotation,
A.2.4.1 Default Whitespace
Handling does not apply. Comments are also not allowed in these
productions.
For example, whitespace is not freely allowed by the direct constructor productions, but is specified explicitly in the grammar, in order to be more consistent with XML.
The following names are not allowed as function names in an unprefixed form because expression syntax takes precedence.
attribute
comment
document-node
element
empty-sequence
function
if
item
namespace-node
node
processing-instruction
schema-attribute
schema-element
switch
text
typeswitch
The grammar in A.1 EBNF normatively defines built-in precedence among the operators of XQuery. These operators are summarized here to make clear the order of their precedence from lowest to highest. The associativity column indicates the order in which operators of equal precedence in an expression are applied.
| # | Operator | Associativity |
|---|---|---|
| 1 | , (comma) | either |
| 2 | FLWOR, some, every, switch, typeswitch, try, if | NA |
| 3 | or | either |
| 4 | and | either |
| 5 | eq, ne, lt, le, gt, ge, =, !=, <, <=, >, >=, is, <<, >> | NA |
| 6 | to | NA |
| 7 | +, - (binary) | left-to-right |
| 8 | *, div, idiv, mod | left-to-right |
| 9 | union, | | either |
| 10 | intersect, except | left-to-right |
| 11 | instance of | NA |
| 12 | treat as | NA |
| 13 | castable as | NA |
| 14 | cast as | NA |
| 15 | -, + (unary) | right-to-left |
| 16 | ! | left-to-right |
| 17 | /, // | left-to-right |
| 18 | [ ] | left-to-right |
In the "Associativity" column, "either" indicates that all the
operators at that level have the associative property (i.e.,
(A op B) op C
is equivalent to A op (B op
C)
), so their associativity is inconsequential. "NA" (not
applicable) indicates that the EBNF does not allow an expression
that directly contains multiple operators from that precedence
level, so the question of their associativity does not arise.
Note:
Parentheses can be used to override the operator precedence in the usual way. Square brackets in an expression such as A[B] serve two roles: they act as an operator causing B to be evaluated once for each item in the value of A, and they act as parentheses enclosing the expression B.
Curly braces in an expression such as validate{E} or ordered{E} perform a similar bracketing role to the parentheses in a function call, but with the difference in most cases that E is an Expr rather than ExprSingle, meaning that it can use the comma operator.
[Definition: Under certain circumstances, an
atomic value can be promoted from one type to another. Type
promotion is used in evaluating function calls (see <IP_ADDRESS> Evaluating Static and Dynamic
Function Calls ), order
by
clauses (see 3.10.8
Order By Clause), and operators that accept numeric
or string operands (see B.2 Operator
Mapping).] The following type promotions are permitted:
Numeric type promotion:
A value of type xs:float
(or any type derived by
restriction from xs:float
) can be promoted to the type
xs:double
. The result is the xs:double
value that is the same as the original value.
A value of type xs:decimal
(or any type derived by
restriction from xs:decimal
) can be promoted to either
of the types xs:float
or xs:double
. The
result of this promotion is created by casting the original value
to the required type. This kind of promotion may cause loss of
precision.
URI type promotion: A value of type xs:anyURI
(or
any type derived by restriction from xs:anyURI
) can be
promoted to the type xs:string
. The result of this
promotion is created by casting the original value to the type
xs:string
.
Note:
Since xs:anyURI
values can be promoted to
xs:string
, functions and operators that compare
strings using the default collation also compare
xs:anyURI
values using the default collation.
This ensures that orderings that include strings,
xs:anyURI
values, or any combination of the two types
are consistent and well-defined.
Note that type promotion is different from subtype substitution. For example:
A function that expects a parameter $p
of type
xs:float
can be invoked with a value of type
xs:decimal
. This is an example of type promotion. The
value is actually converted to the expected type. Within the body
of the function, $p instance of xs:decimal
returns
false
.
A function that expects a parameter $p
of type
xs:decimal
can be invoked with a value of type
xs:integer
. This is an example of subtype
substitution. The value retains its original type. Within the
body of the function, $p instance of xs:integer
returns true
.
The operator mapping tables in this section list the combinations of types for which the various operators of XQuery 3.0 are defined. [Definition: For each operator and valid combination of operand types, the operator mapping tables specify a result type and an operator function that implements the semantics of the operator for the given types.] The definitions of the operator functions are given in [XQuery and XPath Functions and Operators 3.0]. The result of an operator may be the raising of an error by its operator function, as defined in [XQuery and XPath Functions and Operators 3.0]. In some cases, the operator function does not implement the full semantics of a given operator. For the definition of each operator (including its behavior for empty sequences or sequences of length greater than one), see the descriptive material in the main part of this document.
The and
and or
operators are defined
directly in the main body of this document, and do not occur in the
operator mapping tables.
If an operator in the operator mapping tables expects an operand
of type ET, that operator can be applied to an operand of
type AT if type AT can be converted to type
ET by a combination of type promotion and subtype
substitution. For example, a table entry indicates that the
gt
operator may be applied to two xs:date
operands, returning xs:boolean
. Therefore, the
gt
operator may also be applied to two (possibly
different) subtypes of xs:date
, also returning
xs:boolean
.
[Definition: When referring to a type, the term
numeric denotes the types xs:integer
,
xs:decimal
, xs:float
, and
xs:double
.] An operator whose operands and result are
designated as numeric
might be thought of as representing four operators, one for each of
the numeric types. For example, the numeric +
operator
might be thought of as representing the following four
operators:
| Operator | First operand type | Second operand type | Result type |
+ |
xs:integer |
xs:integer |
xs:integer |
+ |
xs:decimal |
xs:decimal |
xs:decimal |
+ |
xs:float |
xs:float |
xs:float |
+ |
xs:double |
xs:double |
xs:double |
A numeric operator may be validly applied to an operand of type
AT if type AT can be converted to any of the four
numeric types by a combination of type promotion and subtype
substitution. If the result type of an operator is listed as
numeric, it means "the first type in the ordered list
(xs:integer, xs:decimal, xs:float, xs:double)
into
which all operands can be converted by subtype
substitution and type promotion." As an example, suppose
that the type hatsize
is derived from
xs:integer
and the type shoesize
is
derived from xs:float
. Then if the +
operator is invoked with operands of type hatsize
and
shoesize
, it returns a result of type
xs:float
. Similarly, if +
is invoked with
two operands of type hatsize
it returns a result of
type xs:integer
.
[Definition: In the operator mapping tables, the
term Gregorian refers to the types
xs:gYearMonth
, xs:gYear
,
xs:gMonthDay
, xs:gDay
, and
xs:gMonth
.] For binary operators that accept two
Gregorian-type operands, both operands must have the same type (for
example, if one operand is of type xs:gDay
, the other
operand must be of type xs:gDay
.)
| Operator | Type(A) | Type(B) | Function | Result type |
|---|---|---|---|---|
| A + B | numeric | numeric | op:numeric-add(A, B) | numeric |
| A + B | xs:date | xs:yearMonthDuration | op:add-yearMonthDuration-to-date(A, B) | xs:date |
| A + B | xs:yearMonthDuration | xs:date | op:add-yearMonthDuration-to-date(B, A) | xs:date |
| A + B | xs:date | xs:dayTimeDuration | op:add-dayTimeDuration-to-date(A, B) | xs:date |
| A + B | xs:dayTimeDuration | xs:date | op:add-dayTimeDuration-to-date(B, A) | xs:date |
| A + B | xs:time | xs:dayTimeDuration | op:add-dayTimeDuration-to-time(A, B) | xs:time |
| A + B | xs:dayTimeDuration | xs:time | op:add-dayTimeDuration-to-time(B, A) | xs:time |
| A + B | xs:dateTime | xs:yearMonthDuration | op:add-yearMonthDuration-to-dateTime(A, B) | xs:dateTime |
| A + B | xs:yearMonthDuration | xs:dateTime | op:add-yearMonthDuration-to-dateTime(B, A) | xs:dateTime |
| A + B | xs:dateTime | xs:dayTimeDuration | op:add-dayTimeDuration-to-dateTime(A, B) | xs:dateTime |
| A + B | xs:dayTimeDuration | xs:dateTime | op:add-dayTimeDuration-to-dateTime(B, A) | xs:dateTime |
| A + B | xs:yearMonthDuration | xs:yearMonthDuration | op:add-yearMonthDurations(A, B) | xs:yearMonthDuration |
| A + B | xs:dayTimeDuration | xs:dayTimeDuration | op:add-dayTimeDurations(A, B) | xs:dayTimeDuration |
| A - B | numeric | numeric | op:numeric-subtract(A, B) | numeric |
| A - B | xs:date | xs:date | op:subtract-dates(A, B) | xs:dayTimeDuration |
| A - B | xs:date | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-date(A, B) | xs:date |
| A - B | xs:date | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-date(A, B) | xs:date |
| A - B | xs:time | xs:time | op:subtract-times(A, B) | xs:dayTimeDuration |
| A - B | xs:time | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-time(A, B) | xs:time |
| A - B | xs:dateTime | xs:dateTime | op:subtract-dateTimes(A, B) | xs:dayTimeDuration |
| A - B | xs:dateTime | xs:yearMonthDuration | op:subtract-yearMonthDuration-from-dateTime(A, B) | xs:dateTime |
| A - B | xs:dateTime | xs:dayTimeDuration | op:subtract-dayTimeDuration-from-dateTime(A, B) | xs:dateTime |
| A - B | xs:yearMonthDuration | xs:yearMonthDuration | op:subtract-yearMonthDurations(A, B) | xs:yearMonthDuration |
| A - B | xs:dayTimeDuration | xs:dayTimeDuration | op:subtract-dayTimeDurations(A, B) | xs:dayTimeDuration |
| A * B | numeric | numeric | op:numeric-multiply(A, B) | numeric |
| A * B | xs:yearMonthDuration | numeric | op:multiply-yearMonthDuration(A, B) | xs:yearMonthDuration |
| A * B | numeric | xs:yearMonthDuration | op:multiply-yearMonthDuration(B, A) | xs:yearMonthDuration |
| A * B | xs:dayTimeDuration | numeric | op:multiply-dayTimeDuration(A, B) | xs:dayTimeDuration |
| A * B | numeric | xs:dayTimeDuration | op:multiply-dayTimeDuration(B, A) | xs:dayTimeDuration |
| A idiv B | numeric | numeric | op:numeric-integer-divide(A, B) | xs:integer |
| A div B | numeric | numeric | op:numeric-divide(A, B) | numeric; but xs:decimal if both operands are xs:integer |
| A div B | xs:yearMonthDuration | numeric | op:divide-yearMonthDuration(A, B) | xs:yearMonthDuration |
| A div B | xs:dayTimeDuration | numeric | op:divide-dayTimeDuration(A, B) | xs:dayTimeDuration |
| A div B | xs:yearMonthDuration | xs:yearMonthDuration | op:divide-yearMonthDuration-by-yearMonthDuration (A, B) | xs:decimal |
| A div B | xs:dayTimeDuration | xs:dayTimeDuration | op:divide-dayTimeDuration-by-dayTimeDuration (A, B) | xs:decimal |
| A mod B | numeric | numeric | op:numeric-mod(A, B) | numeric |
| A eq B | numeric | numeric | op:numeric-equal(A, B) | xs:boolean |
| A eq B | xs:boolean | xs:boolean | op:boolean-equal(A, B) | xs:boolean |
| A eq B | xs:string | xs:string | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
| A eq B | xs:date | xs:date | op:date-equal(A, B) | xs:boolean |
| A eq B | xs:time | xs:time | op:time-equal(A, B) | xs:boolean |
| A eq B | xs:dateTime | xs:dateTime | op:dateTime-equal(A, B) | xs:boolean |
| A eq B | xs:duration | xs:duration | op:duration-equal(A, B) | xs:boolean |
| A eq B | Gregorian | Gregorian | op:gYear-equal(A, B) etc. | xs:boolean |
| A eq B | xs:hexBinary | xs:hexBinary | op:hexBinary-equal(A, B) | xs:boolean |
| A eq B | xs:base64Binary | xs:base64Binary | op:base64Binary-equal(A, B) | xs:boolean |
| A eq B | xs:anyURI | xs:anyURI | op:numeric-equal(fn:compare(A, B), 0) | xs:boolean |
| A eq B | xs:QName | xs:QName | op:QName-equal(A, B) | xs:boolean |
| A eq B | xs:NOTATION | xs:NOTATION | op:NOTATION-equal(A, B) | xs:boolean |
| A ne B | numeric | numeric | fn:not(op:numeric-equal(A, B)) | xs:boolean |
| A ne B | xs:boolean | xs:boolean | fn:not(op:boolean-equal(A, B)) | xs:boolean |
| A ne B | xs:string | xs:string | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean |
| A ne B | xs:date | xs:date | fn:not(op:date-equal(A, B)) | xs:boolean |
| A ne B | xs:time | xs:time | fn:not(op:time-equal(A, B)) | xs:boolean |
| A ne B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-equal(A, B)) | xs:boolean |
| A ne B | xs:duration | xs:duration | fn:not(op:duration-equal(A, B)) | xs:boolean |
| A ne B | Gregorian | Gregorian | fn:not(op:gYear-equal(A, B)) etc. | xs:boolean |
| A ne B | xs:hexBinary | xs:hexBinary | fn:not(op:hexBinary-equal(A, B)) | xs:boolean |
| A ne B | xs:base64Binary | xs:base64Binary | fn:not(op:base64Binary-equal(A, B)) | xs:boolean |
| A ne B | xs:anyURI | xs:anyURI | fn:not(op:numeric-equal(fn:compare(A, B), 0)) | xs:boolean |
| A ne B | xs:QName | xs:QName | fn:not(op:QName-equal(A, B)) | xs:boolean |
| A ne B | xs:NOTATION | xs:NOTATION | fn:not(op:NOTATION-equal(A, B)) | xs:boolean |
| A gt B | numeric | numeric | op:numeric-greater-than(A, B) | xs:boolean |
| A gt B | xs:boolean | xs:boolean | op:boolean-greater-than(A, B) | xs:boolean |
| A gt B | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), 0) | xs:boolean |
| A gt B | xs:date | xs:date | op:date-greater-than(A, B) | xs:boolean |
| A gt B | xs:time | xs:time | op:time-greater-than(A, B) | xs:boolean |
| A gt B | xs:dateTime | xs:dateTime | op:dateTime-greater-than(A, B) | xs:boolean |
| A gt B | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-greater-than(A, B) | xs:boolean |
| A gt B | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-greater-than(A, B) | xs:boolean |
| A gt B | xs:anyURI | xs:anyURI | op:numeric-greater-than(fn:compare(A, B), 0) | xs:boolean |
| A lt B | numeric | numeric | op:numeric-less-than(A, B) | xs:boolean |
| A lt B | xs:boolean | xs:boolean | op:boolean-less-than(A, B) | xs:boolean |
| A lt B | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 0) | xs:boolean |
| A lt B | xs:date | xs:date | op:date-less-than(A, B) | xs:boolean |
| A lt B | xs:time | xs:time | op:time-less-than(A, B) | xs:boolean |
| A lt B | xs:dateTime | xs:dateTime | op:dateTime-less-than(A, B) | xs:boolean |
| A lt B | xs:yearMonthDuration | xs:yearMonthDuration | op:yearMonthDuration-less-than(A, B) | xs:boolean |
| A lt B | xs:dayTimeDuration | xs:dayTimeDuration | op:dayTimeDuration-less-than(A, B) | xs:boolean |
| A lt B | xs:anyURI | xs:anyURI | op:numeric-less-than(fn:compare(A, B), 0) | xs:boolean |
| A ge B | numeric | numeric | op:numeric-greater-than(A, B) or op:numeric-equal(A, B) | xs:boolean |
| A ge B | xs:boolean | xs:boolean | fn:not(op:boolean-less-than(A, B)) | xs:boolean |
| A ge B | xs:string | xs:string | op:numeric-greater-than(fn:compare(A, B), -1) | xs:boolean |
| A ge B | xs:date | xs:date | fn:not(op:date-less-than(A, B)) | xs:boolean |
| A ge B | xs:time | xs:time | fn:not(op:time-less-than(A, B)) | xs:boolean |
| A ge B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-less-than(A, B)) | xs:boolean |
| A ge B | xs:yearMonthDuration | xs:yearMonthDuration | fn:not(op:yearMonthDuration-less-than(A, B)) | xs:boolean |
| A ge B | xs:dayTimeDuration | xs:dayTimeDuration | fn:not(op:dayTimeDuration-less-than(A, B)) | xs:boolean |
| A ge B | xs:anyURI | xs:anyURI | op:numeric-greater-than(fn:compare(A, B), -1) | xs:boolean |
| A le B | numeric | numeric | op:numeric-less-than(A, B) or op:numeric-equal(A, B) | xs:boolean |
| A le B | xs:boolean | xs:boolean | fn:not(op:boolean-greater-than(A, B)) | xs:boolean |
| A le B | xs:string | xs:string | op:numeric-less-than(fn:compare(A, B), 1) | xs:boolean |
| A le B | xs:date | xs:date | fn:not(op:date-greater-than(A, B)) | xs:boolean |
| A le B | xs:time | xs:time | fn:not(op:time-greater-than(A, B)) | xs:boolean |
| A le B | xs:dateTime | xs:dateTime | fn:not(op:dateTime-greater-than(A, B)) | xs:boolean |
| A le B | xs:yearMonthDuration | xs:yearMonthDuration | fn:not(op:yearMonthDuration-greater-than(A, B)) | xs:boolean |
| A le B | xs:dayTimeDuration | xs:dayTimeDuration | fn:not(op:dayTimeDuration-greater-than(A, B)) | xs:boolean |
| A le B | xs:anyURI | xs:anyURI | op:numeric-less-than(fn:compare(A, B), 1) | xs:boolean |
| A is B | node() | node() | op:is-same-node(A, B) | xs:boolean |
| A << B | node() | node() | op:node-before(A, B) | xs:boolean |
| A >> B | node() | node() | op:node-after(A, B) | xs:boolean |
| A union B | node()* | node()* | op:union(A, B) | node()* |
| A | B | node()* | node()* | op:union(A, B) | node()* |
| A intersect B | node()* | node()* | op:intersect(A, B) | node()* |
| A except B | node()* | node()* | op:except(A, B) | node()* |
| A to B | xs:integer | xs:integer | op:to(A, B) | xs:integer* |
| A , B | item()* | item()* | op:concatenate(A, B) | item()* |
| A || B | xs:anyAtomicType | xs:anyAtomicType | fn:concat(A, B) | xs:string |
| Operator | Operand type | Function | Result type |
|---|---|---|---|
| + A | numeric | op:numeric-unary-plus(A) | numeric |
| - A | numeric | op:numeric-unary-minus(A) | numeric |
The tables in this section describe how values are assigned to the various components of the static context and dynamic context, and to the parameters that control the serialization process.
The following table describes the components of the static context. The following aspects of each component are described:
Default initial value: This is the initial value of the component if it is not overridden or augmented by the implementation or by a query.
Can be overwritten or augmented by implementation: Indicates whether an XQuery implementation is allowed to replace the default initial value of the component by a different, implementation-defined value and/or to augment the default initial value by additional implementation-defined values.
Can be overwritten or augmented by prolog: Indicates whether there are prolog declarations that can replace and/or augment the initial value provided by default or by the implementation.
Can be overwritten or augmented by expressions: Indicates whether there are expressions that can replace and/or augment the value of the component for their subexpressions.
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.2.5 Consistency Constraints.
| Component | Default initial value | Can be overwritten or augmented by implementation? | Can be overwritten or augmented by prolog? | Can be overwritten or augmented by expressions? | Consistency rules |
|---|---|---|---|---|---|
| Statically known namespaces | fn , xml , xs ,
xsi , local |
overwriteable and augmentable (except for
xml ) |
overwriteable and augmentable by 4.13 Namespace Declaration | overwriteable and augmentable by element constructor | Only one namespace can be assigned to a given prefix per lexical scope. |
| Default element/type namespace | no namespace | overwriteable | overwriteable by 4.14 Default Namespace Declaration | overwriteable by element constructor | Only one default namespace per lexical scope. |
| In-scope variables | none | augmentable | overwriteable and augmentable by 4.16 Variable Declaration and 3.1.7 Inline Function Expressions, augmentable by 4.12 Module Import | overwriteable and augmentable by variable-binding expressions | Only one definition per variable per lexical scope. |
| Context item static type | none | overwriteable | overwriteable by 4.17 Context Item Declaration | overwriteable by expresssions that set the context item | None. |
| Ordering mode | ordered |
overwriteable | overwriteable by 4.7 Ordering Mode Declaration | overwriteable by expression | Value must be ordered or
unordered . |
| Default function namespace | fn |
overwriteable (not recommended) | overwriteable by 4.14 Default Namespace Declaration | no | None. |
| In-scope schema types | built-in types in xs |
augmentable | augmentable by 4.11 Schema Import | no | Only one definition per global or local type. |
| In-scope element declarations | none | augmentable | augmentable by 4.11 Schema Import | no | Only one definition per global or local element name. |
| In-scope attribute declarations | none | augmentable | augmentable by 4.11 Schema Import | no | Only one definition per global or local attribute name. |
| Statically known function signatures | functions in fn namespace, and constructors for
built-in generalized atomic types |
augmentable | augmentable by 4.12 Module Import and by 4.18 Function Declaration; augmentable by 4.11 Schema Import (which adds constructor functions for user-defined types) | no | Each function must have a unique expanded QName and number of arguments. |
| Default collation | Unicode codepoint collation | overwriteable | overwriteable by 4.4 Default Collation Declaration | no | None. |
| Construction mode | preserve |
overwriteable | overwriteable by 4.6 Construction Declaration | no | Value must be preserve or strip . |
| Default order for empty sequences | implementation-defined | overwriteable | overwriteable by 4.8 Empty Order Declaration | no | Value must be greatest or least . |
| Boundary-space policy | strip |
overwriteable | overwriteable by 4.3 Boundary-space Declaration | no | Value must be preserve or strip . |
| Copy-namespaces mode | inherit, preserve |
overwriteable | overwriteable by 4.9 Copy-Namespaces Declaration | no | Value consists of inherit or
no-inherit , and preserve or
no-preserve . |
| Static Base URI | See rules in 4.5 Base URI Declaration | overwriteable | overwriteable by 4.5 Base URI Declaration | no | Value must be a valid lexical representation of the type xs:anyURI. |
| Statically known decimal formats | specified in static decimal formats | yes | yes, using decimal format declarations | no | See consistency rules in static decimal formats |
| Statically known documents | none | augmentable | no | no | None. |
| Statically known collections | none | augmentable | no | no | None. |
| Statically known default collection type | node()* |
overwriteable | no | no | None. |
| Statically known collations | only the default collation | augmentable | no | no | Each URI uniquely identifies a collation. |
| XPath 1.0 Compatibility Mode | false |
no | no | no | Must be false . |
| Serialization Parameters | |||||
| byte-order-mark | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| cdata-section-elements | empty | overwriteable and augmentable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| doctype-public | none | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| doctype-system | none | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| encoding | implementation-defined choice between "utf-8" and "utf-16" | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| escape-uri-attributes | (not applicable when method = xml) | overwriteable and augmentable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| html-version | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| include-content-type | (not applicable when method = xml) | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| indent | no | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| item-separator | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| media-type | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| method | xml | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| normalization-form | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| omit-xml-declaration | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| standalone | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| suppress-indentation | empty | overwriteable and augmentable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| undeclare-prefixes | no | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| use-character-maps | empty | overwriteable and augmentable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
| version | implementation-defined | overwriteable | overwriteable by prolog | no | Section 3 Serialization Parameters SER30 |
The following table describes the components of the dynamic context. The following aspects of each component are described:
Default initial value: This is the initial value of the component if it is not overridden or augmented by the implementation or by a query.
Can be overwritten or augmented by implementation: Indicates whether an XQuery implementation is allowed to replace the default initial value of the component by a different implementation-defined value and/or to augment the default initial value by additional implementation-defined values.
Can be overwritten or augmented by prolog: Indicates whether there are prolog declarations that can replace and/or augment the initial value provided by default or by the implementation.
Can be overwritten or augmented by expressions: Indicates whether there are expressions that can replace and/or augment the value of the component for their subexpressions.
Consistency Rules: Indicates rules that must be observed in assigning values to the component. Additional consistency rules may be found in 2.2.5 Consistency Constraints.
| Component | Default initial value | Can be overwritten or augmented by implementation? | Can be overwritten or augmented by prolog? | Can be overwritten or augmented by expressions? | Consistency rules |
|---|---|---|---|---|---|
| Context item | the initial context item | overwriteable | no, but the initial context item can be set in the prolog using a 4.17 Context Item Declaration | overwritten during evaluation of path expressions and predicates | The query body and the prolog of every module in a query share the same initial context item. |
| Context position | 1 if the initial context item is set, otherwise none | overwriteable | no | overwritten during evaluation of path expressions and predicates | If context item is defined, context position must be >0 and <= context size; else context position is absentDM30. |
| Context size | 1 if the initial context item is set, otherwise none | overwriteable | no | overwritten during evaluation of path expressions and predicates | If context item is defined, context size must be >0; else context size is absentDM30. |
| Variable values | none | augmentable | overwriteable and augmentable by 4.16 Variable Declaration and 3.1.7 Inline Function Expressions, augmentable by 4.12 Module Import | overwriteable and augmentable by variable-binding expressions | Names and values must be consistent with in-scope variables. |
| Named functions | functions in fn namespace, and constructors for
built-in generalized atomic types |
augmentable | augmentable by 4.18 Function Declaration, 4.12 Module Import, and 4.11 Schema Import ( (which adds constructor functions for user-defined types) | no | Must be consistent with statically known function signatures |
| Current dateTime | none | must be initialized by implementation | no | no | Must include a timezone. Remains constant during evaluation of a query. |
| Implicit timezone | none | must be initialized by implementation | no | no | Remains constant during evaluation of a query. |
| Available documents | none | must be initialized by implementation | no | no | None |
| Available text resources | none | must be initialized by implementation | no | no | None |
| Available node collections | none | must be initialized by implementation | no | no | None |
| Default node collection | none | overwriteable | no | no | None |
| Available resource collections | none | must be initialized by implementation | no | no | None |
| Default resource collection | none | overwriteable | no | no | None |
The following items in this specification are implementation-defined:
The version of Unicode that is used to construct expressions.
The implicit timezone.
The circumstances in which warnings are raised, and the ways in which warnings are handled.
The method by which errors are reported to the external processing environment.
Which version of XML and XML Names (e.g. [XML 1.0] and [XML Names] or [XML 1.1] and [XML Names 1.1]) and which version of XML Schema (e.g. [XML Schema 1.0] or [XML Schema 1.1]) is used for the definitions of primitives such as characters and names, and for the definitions of operations such as normalization of line endings and normalization of whitespace in attribute values. It is recommended that the latest applicable version be used (even if it is published later than this specification).
How XDM instances are created from sources other than an Infoset or PSVI.
Any components of the static context or dynamic context that are overwritten or augmented by the implementation.
The default handling of empty sequences returned by an ordering
key (orderspec) in an order by
clause (empty
least
or empty greatest
).
The names and semantics of any extension expressions (pragmas) recognized by the implementation.
The names and semantics of any option declarations recognized by the implementation.
Protocols (if any) by which parameters can be passed to an external function, and the result of the function can returned to the invoking query.
The process by which the specific modules to be imported by a module import are identified, if the Module Feature is supported (includes processing of location hints, if any.)
The means by which serialization is invoked, if the Serialization Feature is supported.
The default values for the byte-order-mark
,
encoding
, media-type
,
normalization-form
, omit-xml-declaration
,
standalone
, and version
parameters, if
the Serialization Feature is
supported.
The result of an unsuccessful call to an external function (for example, if the function implementation cannot be found or does not return a value of the declared type).
Limits on ranges of values for various data types, as enumerated in 5.3 Data Model Conformance.
Syntactic extensions to XQuery, including both their syntax and semantics, as discussed in 5.4 Syntax Extensions.
Whether the type system is based on [XML Schema 1.0] or [XML Schema 1.1]. An implementation that has based its type system on XML Schema 1.0 is not required to support the use of the xs:dateTimeStamp constructor or the use of xs:dateTimeStamp as TypeName in any expression.
The signatures of functions provided by the implementation or via an implementation-defined API (see 2.1.1 Static Context).
Any environment variables provided by the implementation.
Any rules used for static typing (see <IP_ADDRESS> Static Analysis Phase).
Any serialization parameters provided by the implementation (see 2.2.4 Serialization).n
The means by which the location hint for a serialization parameter document identifies the corresponding XDM instance (see 2.2.4 Serialization).
What error, if any, is returned if an external function's implementation does not return the declared result type (see 2.2.5 Consistency Constraints).
Any annotations defined by the implementation, and their associated behavior (see 4.15 Annotations).
Any function asertions defined by the implementation.
The effect of function assertions understood by the implementation on <IP_ADDRESS> The judgement subtype-assertions(AnnotationsA, AnnotationsB) .
Any implementation-defined variables defined by the implementation. (see 3.1.2 Variable References).
The ordering associated with fn:unordered
in the
implementation (see 3.11
Ordered and Unordered Expressions).
Any additional information provided for try/catch via the
err:additional
variable (see 3.15 Try/Catch Expressions).
The default boundary-space policy (see 4.3 Boundary-space Declaration).
The default collation (see 4.4 Default Collation Declaration).
The default base URI (see 4.5 Base URI Declaration).
Note:
Additional implementation-defined items are listed in [XQuery and XPath Data Model (XDM) 3.0] and [XQuery and XPath Functions and Operators 3.0].
It is a static error if analysis of an expression relies on some component of the static context that is absentDM30 .
It is a dynamic error if evaluation of an expression relies on some part of the dynamic context that is absentDM30 .
It is a static error if an expression is not a valid instance of the grammar defined in A.1 EBNF.
It is a type error if, during the static analysis phase, an expression is found to have a static type that is not appropriate for the context in which the expression occurs, or during the dynamic evaluation phase, the dynamic type of a value does not match a required type as specified by the matching rules in 2.5.5 SequenceType Matching.
During the analysis phase, it is a static error if the static type assigned to an expression
other than the expression ()
or data(())
is empty-sequence()
.
(Not currently used.)
(Not currently used.)
It is a static error if an expression refers to an element name, attribute name, schema type name, namespace prefix, or variable name that is not defined in the static context, except for an ElementName in an ElementTest or an AttributeName in an AttributeTest.
An implementation that does not support the Schema Aware Feature must raise a static error if a Prolog contains a schema import.
An implementation must raise a static error if it encounters a reference to an axis that it does not support.
It is a static error if the set of definitions contained in all schemas imported by a Prolog do not satisfy the conditions for schema validity specified in Sections 3 and 5 of Part 1 of [XML Schema 1.0] or [XML Schema 1.1] --i.e., each definition must be valid, complete, and unique.
It is a static error if an implementation recognizes a pragma but determines that its content is invalid.
(Not currently used.)
(Not currently used.)
An implementation that does not support the Module Feature raises a static error if it encounters a module declaration or a module import.
It is a static error if the expanded QName and number of arguments in a static function call do not match the name and arity of a function signature in the static context.
It is a type error if the result of a path operator contains both nodes and non-nodes.
It is a type
error if E1
in a path expression
E1/E2
does not evaluate to a sequence of nodes.
It is a type error if, in an axis step, the context item is not a node.
(Not currently used.)
It is a static error if a namespace declaration attribute contains an EnclosedExpr.
(Not currently used.)
It is a type error if the content sequence in an element constructor contains an attribute node following a node that is not an attribute node.
It is a dynamic error if any attribute of a constructed element does not have a name that is distinct from the names of all other attributes of the constructed element.
It is a dynamic error if the result of the content
expression of a computed processing instruction constructor
contains the string "?>
".
In a validate expression, it is a dynamic error if the root element
information item in the PSVI resulting from validation does not
have the expected validity property: valid
if
validation mode is strict
, or either
valid
or notKnown
if validation mode is
lax
.
(Not currently used.)
(Not currently used.)
It is a type
error if the argument of a validate
expression
does not evaluate to exactly one document or element node.
It is a static error if the version number specified in a version declaration is not supported by the implementation.
A static error is raised if a Prolog contains more than one base URI declaration.
It is a static error if a module contains multiple bindings for the same namespace prefix.
It is a static
error if multiple functions declared or
imported by a module
have the same number of arguments and their expanded QNames are
equal (as defined by the eq
operator).
It is a static error to import two schema components that both define the same name in the same symbol space and in the same scope.
(Not currently used.)
(Not currently used.)
It is a static error if a Prolog contains more than one default collation declaration, or the value specified by a default collation declaration is not present in statically known collations.
It is a static error for an inline function expression to have more than one parameter with the same name.
It is a static error if the attributes specified by a direct element constructor do not have distinct expanded QNames.
It is a dynamic error if the value of the name
expression in a computed processing instruction constructor cannot
be cast to the type xs:NCName
.
(Not currently used.)
(Not currently used.)
It is a dynamic error the node-name of a node constructed by a computed attribute constructor has any of the following properties:
Its namespace prefix is xmlns
.
It has no namespace prefix and its local name is
xmlns
.
Its namespace URI is
http://www.w3.org/2000/xmlns/
.
Its namespace prefix is xml
and its namespace URI
is not http://www.w3.org/XML/1998/namespace
.
Its namespace prefix is other than xml
and its
namespace URI is
http://www.w3.org/XML/1998/namespace
.
It is a static
error if the name of a function annotation or the
function name in a function declaration is in one of the following
namespaces: http://www.w3.org/XML/1998/namespace,
http://www.w3.org/2001/XMLSchema,
http://www.w3.org/2001/XMLSchema-instance,
http://www.w3.org/2005/xpath-functions
,
http://www.w3.org/2005/xpath-functions/math
,
http://www.w3.org/2012/xquery
.
An implementation MAY raise a static error if the value of a URILiteral or a BracedURILiteral is of nonzero length and is neither an absolute URI nor a relative URI.
It is a static error if multiple module imports in the same Prolog specify the same target namespace.