Thomas Mueller wrote:
by putting JCR on top of XML DB
That would be possible.
Maybe somebody should start doing that!
So leave XPath alone, introduce XQuery to the spec, for instance level 3
compliance or so. And XML DB will be the natural fit for JCR.
And leave AQM as well, so developers will decide what is the best for them to
use. Nobody stopping you to introduce different compliance levels.
It looks like 'data interoperability' means different things for
different people. If the point of data interoperability is "to makes
sharing data easier", then (in my view) this includes existing
systems. Data in existing systems may not be in XML.
You are 100% right. I believe that we should be more specific.
Data interoperability makes data sharing easy, that for sure, but also I look at
data processing as well. Here is a use case:
OpenOffice been used to create a document (XML), now it has been transmitted
to some third party system that has been able to process the document and store
it. (So far it is the core concepts of data interoperability)
From this point document can be stored anywhere: file system, RDBMS, JCR,
XMLDB , ... etc. And it does not affect data interoperability.
But now we want to treat the document not just a stand-alone (blob/xml) entity
but a part of the system data, so some other document can refer to a paragraph
in this document or system can display parts of the document without retrieving
entire thing, or runnig XPath, XQuery on document collection.
And it is the real use case, we are working on the system that manage
unstructured XML data.
"SQLish" language are not capable to work with graph like structures
In JCR (since 1.0), a query returns 'columns', 'rows', and 'nodes'.
SQL returns 'columns', 'rows'.
Full XQuery returns XML. This looks like a problem to me.
It is quite sensitive matter, XQuery can be used to transform results and return
nodes that does not exist in the repository. On the other hand developers would
have full control of it.
I agree. But full XQuery wouldn't make sense in my view.
I think we have written enough, let's go ahead and define the XQuery
subset!
I think the first step would be to define the compliance levels.
I would propose something like that:
Level 1: Read only repository, XPath 1.0, AQM, JQOM
Level 2: Read-write repository, XPath 1.0, AQM, JQOM
Level 3: Read-write repository, basic XQuery, XPath 2.0, AQM, JQOM
Level 4: Read-write repository, XQuery 1.0, XPath 2.0, AQM, JQOM
--
Ivan Latysh
[EMAIL PROTECTED]
