I did a scan of implementation-defined items in XQuery 3.0. I believe that the following are not reflected in Appendix D, Implementation-Defined Items:


2.1.1 Static Context

The statically known function signatures include the signatures of functions from a variety of sources, including built-in functions described in [XQuery and XPath Functions and Operators 3.0], functions declared in the current module (see 4.18 Function Declaration), module imports (see 4.12 Module Import), constructor functions (see 3.16.5 Constructor Functions), and functions provided by an implementation or via an implementation-defined API (see C.1 Static Context Components). It is a static error [err:XQST0034] if two such functions have the same expanded QName and the same arity (even if the signatures are consistent).

2.1.2 Dynamic Context

[Definition: Environment variables. This is a mapping from names to values. Both the names and the values are strings. The names are compared using an implementation-defined collation, and are unique under this collation. The set of environment variables is implementation-defined and may be empty.]

2.2.3.1 Static Analysis Phase

In XQuery 1.0 and XPath 2.0, rules for static type inferencing were published normatively in [XQuery 1.0 and XPath 2.0 Formal Semantics], but implementations were allowed to refine these rules to infer a more precise type where possible. In XQuery 3.0 and XPath 3.0, the rules for static type inferencing are entirely implementation-defined.

2.2.4 Serialization

An output declaration may appear only in a main module; it is a static error [err:XQST0108] if an output declaration appears in a library module. It is a static error [err:XQST0110] if the same serialization parameter is declared more than once. It is a static error [err:XQST0109] if the local name of an output declaration in the http://www.w3.org/2010/xslt-xquery-serialization namespace is not one of the serialization parameter names listed in C.1 Static Context Components or parameter-document. The default value for the method parameter is "xml". An implementation may define additional implementation-defined serialization parameters in its own namespaces.

2.2.4 Serialization

If the local name of an output declaration in the http://www.w3.org/2010/xslt-xquery-serialization namespace is parameter-document, the value of the output declaration is treated as a URI literal. The value is a location hint, and identifies an XDM instance in an implementation-defined way. If a processor is performing serialization, it is a static error [err:XQST0119] if the implementation is not able to process the value of the output:parameter-document declaration to produce an XDM instance.

2.2.5 Consistency Constraints

For each function declared as external: the implementationDM30 must either return a value that matches the declared result type, using the matching rules in 2.5.5 SequenceType Matching, or raise an implementation-defined error.

2.5.5.7 Function Test

Implementations MAY define further annotation assertions, whose behaviour is implementation-defined. Implementations MAY provide a way for users to create their own annotation assertions. Implementations MUST NOT define annotation assertions in the following reserved namespaces; it is an error for users to create annotation assertions in the following reserved namespaces [err:XQST0045]:

2.5.6.3 The judgement subtype-assertions(AnnotationsA, AnnotationsB)

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

3.1.2 Variable References

The in-scope variables may be augmented by implementation-defined variables.

3.11 Ordered and Unordered Expressions

In addition to ordered and unordered expressions, XQuery provides a function named fn:unordered that operates on any sequence of items and returns the same sequence in an implementation-defined order. A call to the fn:unordered function may be thought of as giving permission for the argument expression to be materialized in whatever order the system finds most efficient. The fn:unordered function relaxes ordering only for the sequence that is its immediate operand, whereas an unordered expression sets the ordering mode for its operand expression and all nested expressions.

3.15 Try/Catch Expressions

err:additional item()* Implementation-defined. This variable must be bound so that a query can reference it without raising an error. The purpose of this variable is to allow implementations to provide any additional information that might be useful.

4.3 Boundary-space Declaration

[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 3.9.1.4 Boundary Whitespace.

4.4 Default Collation Declaration

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

4.5 Base URI Declaration

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