jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From IvanLatysh <i...@yourmail.com>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Tue, 17 Jul 2007 19:08:41 GMT
Thomas Mueller wrote:
>> the entire industry moving towards XML data interoperability ...
> Could you explain this a bit more?
I believe I do not understand the question.

In a nutshell ... for instance MSWord save document as XML file, allow third 
party applications to read, understand and transform such document, also allow 
to execure XSLT/XPath/XQuery on the document and it is platform independent.

If you can be a little more specific I will try to answer your question.

>> JCR data model is a native fit to XQuery language that is more
>> powerful and better defined than AQM may ever become.
> Do you suggest that all JCR implementations need to implement the full
> XQuery language? If not, what subset would you suggest?
Yes I do suggest XQuery as JCR main query language.
Full implementation would be too much, so subsets is the way to go.
I believe committee can define implementation levels.

But what is more important is that we set query language boundary wide enough 
allowing it to grow for quite some time making JCR technology stable in the 
longer run.

B.t.w. I integrated Saxon XQuery 1.0 engine into JCR 1.2. it took me .... about 
3 hours. My integration is inefficient and not optimized, but it make a 
statement that integrating XQuery into JCR are more trivial than we may think of.

>> But I strongly believe that AQM is a bad choice.
> Why do you think so?
Because re-inventing the wheel again is not a good path to walk in this case.

>> The right approach would be to pick existing query language
> What is your experience using XQuery? What products do you use?
I use XPath, XSLT, XSL:FO in numerous projects XQuery in a few.
Most of the time we use Saxon.
My experience with XQuery - it is damn powerful.
It is wrong to draw such analogy but you may think about XQuery as XPath + XSLT 
2 in 1.

>> deprecating XPath is an obvious mistake!
> Why?
Here is why:
* JCR operated with Nodes and Properties
* Query language should understand Nodes and Properties
* Persistence should persist Nodes and Properties

Now let's see proposed implementation:
* SQL - is not design to operate with Nodes and Properties
* AQM - design to work with JCR Object model and so has limited functionality 
comparing with XQuery
* RDBMS persistence has no knowledge about Nodes and Properties.

So I propose:
* XQuery - designed to work with Nodes and Properties - 100% match
* XPath - subset of XQuery so 100% match
* XMLDB - design to work with Nodes and Properties plus enable XQuery optimization.

To summarize all this I propose to use 'X' languages to work with 'X' data 

>> From system architect point of view I can say that if JCR will drop XPath
>> support there are no advantages to use JCR for our projects, we will 
>> move to XML
>> database that will provide the same functionality plus native XPath 
>> and XQuery
>> support out of the box.
> Which XML databases do you think about?
eXist - java XMLDB - open source, written in Java, build-in XQuery 1.0 decent 
Berkeley XMLDB - open source reasonable performance and features.
Tamino XMLDB - commercial, has nice features and good performance.

> Why would using XQuery be better than using AQM?
I answered on this question earlier in my letter.

Ivan Latysh

View raw message