 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 225: XQuery API for JavaTM (XQJ)
The following updates have been made to the original proposal: 2009.06.25: Maintenance Lead: Maxim Orgiyan, Oracle E-Mail Address: maxim.orgiyan Telephone Number: +1 650 506 9248, +32 15 30 77 24 Fax Number: -, +32 15 32 12 60 Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: IBM & Oracle Corporation Name of Contact Person: Andrew Eisenberg & Jim Melton E-Mail Address: andrew.eisenberg@us.ibm.com & jim.melton@oracle.com Telephone Number: +1 978 399 5158 & +1 801 942 0144 Fax Number: +1 978 399 5117 & +1 801 942 3345 Specification Lead: Andrew Eisenberg & Jim Melton E-Mail Address: andrew.eisenberg@us.ibm.com & jim.melton@oracle.com Telephone Number: +1 978 399 5158 & +1 801 942 0144 Fax Number: +1 978 399 5117 & +1 801 942 3345 Initial Expert Group Membership: BEA Systems, Inc - Nitin Mangtani Supporting this JSR: BEA Systems, Inc Section 2: Request
2.1 Please describe the proposed Specification:XQuery 1.0 is a query language being developed by the W3C XML Query Language Work Group. The XQuery 1.0 specification includes the following statement in its introduction: XQuery is ... designed to be a language in which queries are concise and easily understood. It is also flexible enough to query a broad spectrum of XML information sources, including both databases and documents. This specification will define a set of interfaces and classes that enable an application to submit XQuery queries to an XML data source and process the results of these 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. This specification relates to XQuery in the same way that JDBC relates to SQL. The specification may also provide the ability to submit XPath 2.0 expressions to an XML data source (XPath 2.0 is not a proper subset of XQuery 1.0 in the latest public working drafts). This specification may allow an application to specify queries using XQueryX, the XML representation of XQuery queries. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2SE. 2.3 What need of the Java community will be addressed by the proposed specification?The proposed specification will allow applications to submit XQuery queries to an XML data source and operate on the result of these queries. 2.4 Why isn't this need met by existing specifications?Existing specifications for accessing databases 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. 2.5 Please give a short description of the underlying technology or technologies: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. A number of vendors are developing implementations of XQuery as drafts of the XQuery 1.0 specification are published (see http://www.w3.org/XML/Query#products for a list of such implementations). 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.xml.xquery 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.8 Are there any security issues that cannot be addressed by the current security model?No. There will be a need for session-based authentication along the same lines as JDBC. 2.9 Are there any internationalization or localization issues?No 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. There are some possible interactions and opportunities for integration that will be investigated by the Expert Group. These include:
JSR 31 (XML Data Binding) 2.11 Please describe the anticipated schedule for the development of this specification.This specification is based on XQuery 1.0 specification that is being progressed in W3C. Our progression in JCP will depend on XQuery 1.0 reaching specific W3C milestones (Last Call Working Draft, Candidate Recommendation, Proposed Recommendation, and Recommendation). We are unable to say when the XQuery 1.0 specification will reach these milestones. The Charter for the XML Query WG and the schedule for XQuery 1.0 are considered to be member confidential by W3C.
Expert Group Formed:
Community Draft:
Public Review Draft:
Final Release:
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.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 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 Spec Leads agree to be guided in their decisions on major issues by a consensus of the Expert Group, which will require the agreement of 2/3 of the Expert Group members. Some members of the Expert Group will be designated as Reviewing Members. These members have indicated that they expect to have a lower degree of participation than other members of the Expert Group. Reviewing Members will be non-voting members of the Expert Group. The two Spec Leads have divided the responsibilities as follows: 1. IBM and Oracle will jointly deliver the specification. 2. Oracle will deliver the reference implementation (RI) and collaborate in delivering the Specification. 3. IBM will deliver the Technology Compatibility Kit (TCK) and collaborate in delivering the Specification. 2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Stand-alone. 2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The 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 JSPA. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.XQuery 1.0: An XML Query Language
XML Query Use Cases
XML Path Language (XPath) 2.0
XQuery 1.0 and XPath 2.0 Data Model
XQuery 1.0 and XPath 2.0 Formal Semantics
XML Syntax for XQuery 1.0
XSLT 2.0 and XQuery 1.0 Serialization
Oracle has defined a Java API as part of their XQuery Prototype http://otn.oracle.com/sample_code/tech/xml/xmldb/xmldb_xquerydownload.html X-Hive DataDirect Technologies has an existing Java API specification available on request BEA has an existing Java API specification available on request 3.2 Explanation of how these items might be used as a starting point for the work.The Expert Group will analyze and compare the existing APIs for XQuery. The group will then create a set of requirements for this API, generate a baseline specification, and then work on refining that specification Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.The Expert Group will consider a number of proposed requirements in determining the scope of the work. The following list of proposed requirements do not consistently follow RFC 2119 in their use of ?must?, ?should?, and ?may?: 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). |
