[
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
