Hello All!
I want to summarize the feedback that I posted to JR mailing list.
I am confused why committee dropping XPath support when the entire industry
moving towards XML data interoperability ...
I do not see any advantages of dropping XPath and replacing it with home-grown
query language when obvious next logical step for JCR would be to introduce
XQuery language. JCR data model is a native fit to XQuery language that is more
powerful and better defined than AQM may ever become.
It is understandable that committee want to introduce an intermediate query
language that JCR will natively understand and other query dialects will be
transformed into it. But I strongly believe that AQM is a bad choice. The right
approach would be to pick existing query language that can work with XML style
data model that JCR operate with.
Also I would understand deprecation of SQL, but deprecating XPath is an
obvious mistake !
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.
I would highly suggest to give it the second thought and re-consider your
decision.
===== PROPOSAL ======
1) I propose to include XQuery (XPath is a subset of XQuery) support as
standard option and make it an intermediate query language.
2) Make SQL as a standard option and transform it to XQuery.
3) Make AQM as an option that will transform queries into XQuery.
By making such changes you open an option for JCR to utilize XML database
persistent storage option that will improve JCR performance dramatically, since
most of the XML databases have XQuery optimization algorithms.
===== PROPOSAL ======
P.S. If you check JR mailing list you will see that some other dev. teams are
raising the same concerns.
--
Ivan Latysh
[EMAIL PROTECTED]
