A Java Specification Request XQuery API for Java (XQJ) submitted by IBM and Oracle Corporation has been published through the Java Community Process (JCP). The specification design goal is to "develop a common API that allows an application to submit queries conforming to the W3C XQuery 1.0 specification to an XML data source and to process the results of such queries. The design of the API will also take into account precedents established by other JSRs, notably JDBC and JAXP. SQL, developed by INCITS H2 and ISO/IEC JTC 1/SC32/WG3, is the query language supported by many relational DBMSs. JDBC is the Java API that allows an application to submit SQL requests to an RDBMS and process the results of the query. The XQuery API for Java (XQJ) specification relates to XQuery in the same way that JDBC relates to SQL. The XQJ specification may provide the ability to submit XPath 2.0 expressions to an XML data source. It may also allow an application to specify queries using XQueryX, the XML representation of XQuery queries. The final XQJ Specification, Reference Implementation, and Technology Compatibility Kit will be made available on a Royalty-Free basis, with commonly-used disclaimers on warranties on the technologies; a reciprocal license will be required as per Section 5C of the Java Specification Participation Agreement (JSPA)." This JSR has received support from BEA, DataDirect Technologies, IBM, Oracle Corporation, Sun Microsystems, Sybase, and X-Hive Corporation.

Bibliographic Information

XQuery API for Java (XQJ). Java Specification Request. Reference: JSR #225. Specification Leads: Andrew Eisenberg (IBM) and Jim Melton (Oracle). Produced under Java Community Process Version 2.5. Status: JSR Review Ballot June 23, 2003. Initial Expert Group Membership: Nitin Mangtani (BEA Systems, Inc), Marc Van Cappellen (DataDirect Technologies), Jan-Eike Michels (IBM), Muralidhar Krishnaprasad (Oracle Corporation), Eduardo Pelegri-Llopart (Sun Microsystems, Inc), and Josh Meckler (Sybase).

Details on the XQJ JSR

Existing specifications for accessing databases [do not meet the requirements of this JSR because they] focus on the relational model. These include JDBC, as well as higher-level APIs such as JDO and Rowsets. There is no existing API for querying XML data.

The XQuery language allows queries to be executed against individual XML documents or collections of XML documents. The results of queries are instances of the XML Query Data Model. These instances include simple values (e.g., numbers, strings), XML nodes, and sequences of both values and XML nodes. XQuery can operate on physical XML documents or virtual XML documents that have been derived from sources of data such as relational or object databases.

Once this JSR is approved, invitations to participate in the Expert Group will be sent to Java Community Process members and members of the W3C XML Query WG and the W3C XSL WG. This specification will be developed iteratively by the Expert Group using email and telephone conferencing as the primary mechanisms for communication. Occasional face-to-face meetings may also be held, possibly co-located with W3C XML Query WG or JavaOne meetings if the membership proves to overlap significantly.

The Expert Group will consider a number of proposed requirements in determining the scope of the work. [For example]:

1. The API should achieve stylistic consistency with existing JAXP and JDBC interfaces, possibly reusing classes from those packages if appropriate.
2. A connection-oriented interface, with transaction support, along the lines of JDBC must be defined.
3. It must be possible to create a XQJ connection from a JDBC connection. This capability may not be provided by all XQJ implementations.
4. There may be a need for a connectionless (single-shot) interface, especially for simple XPath use.
5. There should be no assumptions about the protocol stack in use.
6. The interface should be equally suitable for use where the client and server are remote and where they are co-located.
7. The interface may allow an application to discover the XML documents and collections that can be queried.
8. The interface should allow the application to have full control over the static and dynamic context of a query.
9. The interface should allow a query to be compiled once and executed repeatedly.
10. The interface should support both the textual and XML representations of a query.
11. It should be possible to parameterize a query (if this feature is supported in XQuery). Discovery and binding of the input parameters should be supported.
12. It may be possible to invoke a named XQuery that is stored on the server.
13. It must be possible to process query results using JAXP and StaX (Streaming API for XML, JSR 173 in process). It might be possible to use other interfaces such as JDOM or DOM4J via a pluggable interface.
14. It must be possible to process any result that XML Query can deliver, in particular a general sequence. Where a query returns nodes, the references to these nodes must be in a form that allows the persistent data to be updated. [This implies a difference between returning references to persistent nodes and nodes constructed by the query.]
15. The interface should allow incremental delivery of results through some kind of cursor or iterator mechanism.
16. The interface should allow XQuery results to be serialized, reusing the JAXP serialization mechanisms.
17. It may be possible to materialize the result of one query for use in subsequent queries, within the same connection. [textual material adapted from the JSR]

Comments from the XML-DEV Forum

From Jonathan Robie, JSR 225 - XQJ: JDBC for XQuery: "Oracle and IBM have now submitted JSR 225, the XQuery API for Java (XQJ). This API performs essentially the same role as JDBC, except that it is for XQuery rather than SQL, and is based on XML rather than the relational model... [there is plenty of experience with proprietary XML DB APIs by the various XML DBMS vendors to draw on] as well as experience with retrieving SQL/XML results via JDBC, proprietary APIs from the XML database community, and a variety of other related APIs. And it's worth mentioning that there have been XQuery APIs per se since the Kweelt API in September, 2000. The submission refers to XQuery APIs designed by BEA, Oracle, and DataDirect, but I know there are others designed by Software AG, Infonyte, e-XMLMedia, Microsoft ... I don't think this list is at all complete. The API basically has to be able to issue a query against data sources and retrieve a result, presenting the result using one of the existing standard XML APIs. At that level, I doubt that the detailed changes in the XQuery language affect the API significantly at all..."

From Mike Champion, JSR 225 - XQJ: JDBC for XQuery: "There will be a year or two before XQuery becomes a Recommendation <duck> for XQJ and XQuery to inform one another and to benefit from each other's implementation experience. Also, there is plenty of experience with proprietary XML DB APIs by the various XML DBMS vendors to draw on (maybe not for full XQuery, but for much of the subset of XQuery that ordinary mortals will actually use, aka XPath 1.0 <duck>). In Gosling's terms, XML DBMS querying APIs appear to be just now entering the 'window of standardization'. If the industry waits much longer, the political interest, i.e., the dominant vendors not wanting to inconvenience their customers by agreeing to standards that break existing applications, will become dominant and the window will have closed..."

From Michael Kay, JSR 225 - XQJ: JDBC for XQuery: "I think you will find that the proponents of this JSR have already collected information about at least half-a-dozen different existing XQuery APIs. Also there are established APIs for XSLT, XPath, and SQL databases that provide opportunities for re-use. It's high time to stop inventing new XQuery APIs and start converging on a single one."