db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Date Fri, 18 Aug 2006 00:06:16 GMT
    [ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12428837 ] 
A B commented on DERBY-688:

As I was writing up the documentation for the XML operators, I was also double-checking the
features to make sure they were all in-line with the SQL/XML[2006] specification.  After some
searching around I've realized that there are two ways in which the current XML operators
are not in line with the spec:

  1. Currently one can use XMLQUERY to retrieve a single element
     node from an XML value and then insert that element directly
     into another Derby XML column.  However, SQL/XML spec says
     that a column of type XML(DOCUMENT)--which is what Derby's
     columns are--can only store actual DOCUMENT nodes; element
     nodes cannot be implicitly "morphed" into document nodes.
     Instead, one must use the XMLDOCUMENT() operator, which is
     not yet implemented in Derby.  So basically, I have to make
     changes to disallow this kind of insertion.

  2. When serializing the results of an XMLQUERY operator, the
     current code doesn't strictly follow the SQL/XML specification,
     which dictates that the sequence must be "normalized" before
     it is serialized.  The rules for normalization can be found


     So changes have to be made in SqlXmlUtil.serializeToString()
     to implement these rules.

Thus, there are still two outstanding code-related tasks for DERBY-688:

  A. Fix SQLSTATEs: I have a patch ready, just haven't posted it yet.
     Will try to do it soon.

  B. Resolve two situations listed above w.r.t to following SQL/XML

I think both of these things need to be completed for the 10.2 release in order to 1) make
sure Derby is a standards-based database, per the charter, and 2) minimize likelihood for
"Existing Application Impact" issues in subsequent releases (caused by having to change behavior
or sqlstates).

> Enhancements to XML functionality to move toward XPath/XQuery support...
> ------------------------------------------------------------------------
>                 Key: DERBY-688
>                 URL: http://issues.apache.org/jira/browse/DERBY-688
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, SQL
>            Reporter: A B
>         Assigned To: A B
>            Priority: Minor
>         Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, d688_phase1_v2.patch,
d688_phase1_v3.patch, d688_phase2_v1_code.patch, d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch,
d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, d688_phase3_v1_tests.patch, d688_phase4_v1.patch,
d688_phase4_v2.patch, d688_phase5_v1.patch, derbyXMLSpec.html
> As of DERBY-334, Derby has some very basic support for XML that consists of an XML datatype
and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS).  I would like to enhance this
existing functionality and, by doing so, help to move Derby incrementally toward a more usable
and more complete XPath/XQuery solution (with emphasis on "incrementally").
> I have attached to this issue a document describing the particular changes that I am
looking to make.  At a high level, they consist of:
> 1) Making it easier to use the XML operators and datatype from within JDBC (ex. by implicit
parsing/serialization of XML values).
> 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results of an XPath
expression (instead of just determining whether or not the expression evaluates to an empty
sequence, which is what XMLEXISTS does).
> 3) Making changes to the existing operators to line them up with the SQL/XML 2005 specification,
and also to take steps toward my eventual hope of having support for XQuery (as opposed to
just XPath) in Derby.
> If anyone has time and interest enough to look at the document and provide feedback,
that'd be great...

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message