Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of david.nuescheler@gmail.com
 designates 209.85.146.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ZxoRlseM+pGsMsfG9I6AT7UxdrjJxX0RmegBWo9wG4QsaxSQZB2jnBaPRinm7wTyP6I4sak5thkSB0Z5j16gHnwMmQTyO2GhVe+HyyG9dc9KyUPfN2YlGWvD7bT7KwdRos7l1FmJeSWrcYrUkW6VZUAOdPPQHRqYBcuzt6W6Zcc=
Message-ID: <eb7e2190707171023h783d0d75r9c6c6fd8e1109397@mail.gmail.com>
Date: Tue, 17 Jul 2007 19:23:34 +0200
From: "David Nuescheler" <david.nuescheler@gmail.com>
To: ivan@yourmail.com
Subject: Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Cc: jsr-283-comments@jcp.org, users@jackrabbit.apache.org
In-Reply-To: <469CD2C6.6000905@yourmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <469CD2C6.6000905@yourmail.com>

Hi Ivan,

thanks for your feedback.

The expert group of JSR-283 will certainly consider your comment when
revisiting the Query discussion.

Let me try to make an argument for the way the specification is right now
and why I think it is the correct way to specify it this way.

In the expert group there was a lot of debate over query syntax and languages,
that I somehow see repeated here:
Comments like  "Xquery is where everybody is going" vs. "SQL is what everybody
knows" vs "SparQL is way better" vs. "Xpath is good for hierarchies" vs.
"Google-style syntax is understood by endusers" which tend to be
unfruitful discussions and mostly emotional.

I think the syntax that one prefers to query the content repository
varies greatly by user (developer) and by usecase.
In the end is a matter of a taste (and a parser) and therefore not all
that relevant.

The important thing really is what kind of operations the index of a
content repository can support. To define that abstractly and free
from the syntax and the language, we defined the AQM.

The AQM reflects what content repositories can support in their query
index and what we can get consensus on to put it into the specification
within the expert group.

If you are looking for extensions on a functional level to the AQM please
feel free to propose those. Please keep in mind that they will probably
require extensions to the query index of existing content repositories and
it is my experience that repostiory vendors are very reluctant to change
modify this very core piece of their repository.

It is clear that a full XQuery implementation requires features in the index
that go far beyond what the repository vendors have in their current and
foreseeable implementations.
Therefore it is not a good candidate for a standard that should provide
interoperability amongst real-life content repositories.
As much as we can all agree that XQuery is probably the most powerful
query language, it does not help if we bake it into a spec that cannot
be implemented by the repository vendors.

To consider a subset of XQuery becomes tricky from a specification
perspective. In JSR-170 we tried to use Xpath and scratch out all
the features that were not mandatory and added all the extension
that we required to cover very basic queries. Which lead to a very
confusing specification.
I would be very afraid to even attempt to do that same exercise
with a spec of the size of Xquery.

I think that it is very important that the AQM expresses a positive list
of features that a content repository query engine supports and the
JQOM allows people to express their queries (within the limitations
of the repository index) in a language neutral way.

It has always been the idea of JCR to allow people to choose their own
query language or syntax to express their query. Thats why in JCR v1.0
we made the query languages that a repository supports discoverable.

In my mind the JQOM allows for a much better way of extending into
additional query languages since it removes the dependencies to
the content repository implementation.

The Jackrabbit community will certainly provide for example an
Xpath parser that (based on JQOM) will work with all repositories.
I know that people from the RDF community are working on a
SparQL parser for JCR and again the JQOM will allow them to do that
in a repository implementation neutral way.
As for XQuery, I think that an XQuery parser sitting on top of JQOM would
be an excellent contribution to Jackrabbit aswell.

I think that AQM and JQOM will allow every developer to choose the
query language that they like best, and therefore provides a much
more open interface to the query facilities that we are able to standardize
for content repositories.

Of course every JCR implementation is free to support features that
go beyond the query features that are mandated by the AQM.

Maybe this explanation helps to rationalize the current specification and
thanks again for your input, we will certainly consider it.

regards,
david

On 7/17/07, IvanLatysh <ivan@yourmail.com> wrote:
> 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
> ivan@yourmail.com
>