SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Notices
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance
| Introduction
| XSLT 2.0 conformance
| XPath 2.0 conformance
| XQuery 1.0 Conformance
| XML Schema 1.0
| XML Schema 1.1
| Serialization
| XQuery Update 1.0
| Conformance with other specifications
| Character Encodings Supported
| JAXP Conformance
» | XQJ Conformance

# XQJ Conformance

Saxon implements XQJ, the XQuery API for Java defined in JSR 225. The current version that is implemented is the Proposed Final Draft 1.0 dated 19 October 2007, which was announced on 20 November 2007.

The compliance definition for XQJ (section 3 of the specification) requires a statement of how all aspects of the specification that are implementation-defined have been implemented. The following table provides this statement for the Saxon implementation.

Implementation-defined feature | Saxon implementation
The class name of the XQDataSource implementation | `net.sf.saxon.xqj.SaxonXQDataSource`
All properties defined on the XQDataSource implementation | Currently none. (Saxon can be configured by associating a Saxon `Configuration` with the `XQDataSource`, and setting properties on the underlying `Configuration`).
The syntax and semantics for commands, assuming executing commands through XQExpression is supported. | No commands are supported (only XQuery expressions).
Is cancelling of query execution supported? | No, Query execution cannot be cancelled.
The default and supported values for each parameter described in XQuery Serialization | Although this is implementation-defined, the test suite makes some assumptions and these have been followed. The defaults are: byte-order-mark="no" cdata-section-elements="" doctype-public=null doctype-system=null encoding="utf-8" indent="yes" media-type="application/xml" method="xml" normalization-form="none" omit-xml-declaration="yes" standalone="omit" undeclare-prefixes="no" use-character-maps="" version="1.0"
Additional StAX or SAX event types being reported, beside the event types documented in [the] specification | None.
Support for XDM instances and types based on user-defined schema types | When used with Saxon-SA, user-defined schema types are supported, to the extent that the XQJ interface allows them to be used.
The semantics with respect to node identity, document order, and full node context, when a node is bound to an external variable. | When a node is bound to an XQItem and hence to a variable in a query, node identity, document order, and "context" (relationships to other nodes) are maintained.
Is login timeout supported? | No. (There is no concept of login.)
Atr transactions supported? | No. Saxon XQuery is read-only.
Behaviour of the `getNodeUri()` method, defined on `XQItemAccessor`, for other than document nodes. | The method is defined on any node, and returns the URI of the external entity in which the containing element originally appeared, if known, or the empty URI otherwise.
Behaviour of the `getTypeName()` method, defined on `XQItemType`, for anonymous types. | Anonymous types have a system-generated name.
Behaviour of the `getSchemaURI()` method, defined on `XQItemType` | The system identifier (document URI) of the original schema document is reported if the information is available.
Behaviour of the `createItemFromDocument` methods, defined on `XQDataFactory`, if the specified value is not a well-formed XML document. | An exception is thrown.
Behaviour of the `bindDocument` methods, defined on `XQDynamicContext`, if the specified value is not a well-formed XML document. | An exception is thrown.
The error codes, reported through `XQQueryException`, in addition to the standard error codes listed in [XQuery] and its associated specifications. | None. The Saxon implementation does not currently use the class `XQQueryException`.

Section 19 of the XQJ specification ("Interoperability") suggests that an XQJ specification should accept items and built-in types that were created using a different vendor's XQJ implementation. In general, Saxon will only handle the Saxon implementation of XQJ interfaces. At any rate, it has not been validated with third-party implementations.