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
     here:

     http://www.w3.org/TR/xslt-xquery-serialization/#serdm 

     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
     specifications.

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

        

Mime
View raw message