This interface is based on the "CommonHandler" concept defined in early drafts of XQJ.
All Saxon implementations of XQItemAccessor must implement this interface
This class represents the common ability of many XQJ classes to be closed.
Saxon implementation of the XQL interface XQConnection.
Saxon implementation of the XQJ interface XQDataFactory.
Saxon implementation of the XQJ XQDataSource interface.
Saxon implementation of the XQJ DynamicContext interface
Saxon implementation of the XQJ XQExpression interface
The class is a Saxon implementation of the XQJ interface XQResultSequence.
This Saxon class is used to implement both the XQItem and XQResultItem interfaces in XQJ.
Saxon implementation of the XQJ XQItemType interface
Saxon implementation of the XQMetaData interface
Saxon implementation of the XQJ interface XQPreparedExpression.
Saxon implementation of the XQSequence interface in XQJ, which represents an XDM sequence together with a current position.
Saxon implementation of the XQJ SequenceType interface
Saxon implementation of the XQJ XQStaticContext interface
This class provides all the conversion methods used to convert data between XDM values and Java values in the XQJ API.
This package contains an implementation of the XQJ specification defined in JSR 225. This API never became part of the Java Standard Edition platform, but it is supported by a variety of Java-based XQuery engines.
Saxon's implementation of the
XQDataSource class is
net.sf.saxon.xqj.SaxonXQDataSource. Generally, this is the only class
that applications need to access directly (all other access can be done by using
standard XQJ interfaces). However, if there is a need to mix XQuery access with other
Saxon functionality such as schema processing, then it is often useful to cast the
XQJ objects to their underlying Saxon implementation classes, which make additional
In general it is not possible to mix Saxon implementation classes of the XQJ interface with implementation classes from other vendors. That is, if an interface specifies that a value of an XQJ type must be passed as an argument, Saxon in general requires the value to belong to a Saxon implementation of that interface.
Although this implementation of XQJ is issued under the open source Mozilla Public License, users should be aware of the terms and conditions included in the XQJ specification (JSR 225) which may (under some interpretations) restrict the right to make modifications. In particular, the terms and conditions published in JSR 225 require implementations to pass the compatibility tests, and to contain no extensions. Because the terms and conditions for the XQJ specification do not comply with some definitions of "open source", the XQJ module is not included in the standard Saxon-HE jar files, but is issued separately.
JSR 225 was published to work with XQuery 1.0, and as a result, it does not support the
richer type system of XQuery 3.1. For example, there are no mechanisms to supply maps and arrays
as input to a query, or to handle maps and arrays in the query result. It is possible to work
around some of these limitations by customizing the
with a user-written
net.sf.saxon.xqj.ObjectConverter, provided you are confident that
you are not thereby violating Oracle's licensing rules.
Despite the prohibitions on extending the JSR 225 interface, Saxonica's implementation of XQJ does allow XQuery 3.1 syntax to be used within the queries submitted for execution.
Copyright (c) 2004-2021 Saxonica Limited. All rights reserved.