Proposal to enhance existing XML functionality in Derby in the following ways:

  1. Add support for setting/getting XML values from a JDBC 3.0 app (without requiring explicit XMLPARSE and XMLSERIALIZE operators). This includes returning meaningful metadata and defining the proper getXXX/setXXX support.
  2. Slight modifications to existing XML operators to comply with SQL/XML.
  3. New XMLQUERY operator for retrieving XML query results.

Specification initially posted to DERBY-688. Relevant discussion is buried in different threads, found here:

Please continue any discussion on the derby-dev mailing list; this page will be updated to summarize the discussion.


Current Discussions

Discussion: JDBC 4.0

While JDBC 4.0 defines support for a "java.sql.SQLXML" class (see SQLXML), implementation of that class and associated APIs will not be part of this proposal. I will try to avoid making changes/decisions for this proposal that might interfere with future JDBC 4.0 support for SQLXML, but I will not be making changes that are specific to JDBC 4.0; any such changes will have to be part of a separate effort.

Discussion: JDBC metadata and getXXX/setXXX methods

After reading through the relevant parts of the above-mentioned thread, I plan to code the following behavior for XML in JDBC 3.0:

Discussion: Xerces and Xalan dependencies

As part of my work for these XML enhancements, I'm removing the explicit dependency on Xerces that exists in 10.1. Instead, the XML parser will be picked up from the JVM, based on existing JDBC 3.0 API calls (JAXP) in the javax.xml.parsers package. If no such parser is found, we will generate an error message saying that a valid parser is required for use of XML. My reason for removing this hard-coded dependency on Xerces is that different JVMs have different XML parsers and we don't want to force users of Derby to download a specific XML parser if we can avoid it. Instead, we can use the JAXP API to pick up the parser that comes with the JVM. An example of why this is useful can be seen with Sun JVM verses IBM JVM: the former comes with Crimson, the latter with Xerces; by changing Derby to use the JAXP API, we ensure that XML will work with both JVMs without requiring a specific parser to be in the user's classpath.

As for Xalan, I plan to retain Derby's dependency on Xalan for four reasons:

  1. the JDBC 3.0 API for evaluation of XPath/XQuery expressions is limited to the javax.xml.transform.* packages, which (in my experience) makes it difficult to process the full results of an XPath/XQuery expression, and is also a bit slow;
  2. Xalan provides a lower-level API for evaluating XPath expressions that, based on some very simple tests I've run, provides much better evaluation performance than the transform API, and allows easier manipulation of the results;
  3. both Sun and IBM JVMs come with Xalan embedded, which means two of the most commonly used JVMs will work with Xalan-dependent code as they are, requiring no additional downloads.
  4. Xalan is an XPath processor, and it is my hope that at some point in the near future we will be able to find a full XQuery processor to use for (and hopefully embed within?) Derby. Thus, our dependency on Xalan is hopefully not a permanent one.

For JVMs that are earlier than JDBC 3.0 and/or for any JVMs that do not include Xalan (ex. do j9 and Apple JVMs include Xalan?), users who wish to use Derby XML will have to put the missing jar files (JAXP parser implementation and/or Xalan) in their classpaths. That done, everything else should work as normal.

XmlEnhancements (last edited 2009-09-20 22:11:12 by localhost)