This section defines the conformance criteria for an XQuery 4.0 processor. In this section, the following terms are used to indicate the requirement levels defined in [RFC2119]. [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 6.1 Minimal Conformance. In addition to a claim of Minimal Conformance, it MAY claim conformance to one or more optional features defined in 6.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 6.2 Optional Features to be optional. If an implementation does not provide a given optional feature, it MUST implement any requirements specified in 6.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.1], as specified in 6.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 4.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 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 4.25 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.
If an implementation provides the Schema Aware Feature, it MUST also provide the 6.2.2 Typed Data Feature.
[Definition: The
Typed Data Feature permits an XDM instance to contain element
node types other than xs:untyped
and attributes node types other
than xs:untypedAtomic
.]
If an XQuery implementation does not provide the Typed Data Feature, it MUST guarantee that:
The XDM has the type xs:untyped
for every element node and
xs:untypedAtomic
for every attribute node, including nodes
created by the query.
Elements constructed by the query always have the type
xs:untyped
; attributes constructed by the query always have
the type xs:untypedAtomic
. (This is equivalent to using
construction mode = strip
.)
[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 MUST NOT report type errors during the static analysis phase except 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.3.4 Serialization.] A conforming XQuery implementation that provides the Serialization Feature MUST conform to 2.3.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.1], 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.7.3 fn:serialize
FO31. 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 item other than a map or array.]
An implementation that does not provide the Higher-Order Function Feature MUST raise a static error [err:XQST0129] if it encounters a TypedFunctionTest, named function reference, inline function expression, or partial function application. The effect of this rule is that it is impossible to construct function items other than maps and arrays. Dynamic function calls are permitted, but the function that is called will necessarily be a map or array. The AnyFunctionTest sequence type is permitted and will match either a map or array. 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 all higher-orderFO31 functions defined in [XQuery and XPath Functions and Operators 4.0]. 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.1]. 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 DM31, 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 DM31, which defines a normative way to construct an XDM instance from an XML document that is governed by a W3C XML Schema.
Support for versions of XML and XSD. As stated in [XQuery and XPath Data Model (XDM) 3.1], 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.
This limit SHOULD be at least 20 digits in order to
accommodate the full range of values of built-in subtypes of xs:integer
, such as
xs:long
and xs:unsignedLong
.
For the types xs:date
, xs:dateTime
, xs:gYear
, and xs:gYearMonth
: the minimum and maximum value of the year component (must be at least 1 to 9999).
For the types xs:time
and xs:dateTime
: 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
might be limited by available memory.
Note:
For discussion of errors due to implementation-dependent limits, see 2.4.1 Kinds of Errors.
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.