Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: softfail (herse.apache.org: transitioning domain of
 ivan@yourmail.com does not designate 206.190.36.81 as permitted sender)
Message-ID: <469F70AE.9050704@yourmail.com>
Date: Thu, 19 Jul 2007 10:09:50 -0400
From: IvanLatysh <ivan@yourmail.com>
Organization: Assent Marketing Inc.
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
References: <469CD2C6.6000905@yourmail.com>
	 <5f211bd50707170913j2679c06bi5b8549dd3157741e@mail.gmail.com>
	 <469D13B9.9080003@yourmail.com>
	 <5f211bd50707180050p3a719419s4cd1ce1c045b7149@mail.gmail.com>
	 <76a6ebd00707180915j23f15a93x8a346e26918953f5@mail.gmail.com>
 <5f211bd50707190240w59988970q4664360eb9355a52@mail.gmail.com>
In-Reply-To: <5f211bd50707190240w59988970q4664360eb9355a52@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
ivan@yourmail.com