jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Tue, 17 Jul 2007 17:04:54 GMT
Hi All,

Thanks a lot for the feedback. It is very important as a part of a Public
Review to get this feedback from the user community to validate if
we are on the right track in the specification process.

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.
Both in the expert group and seemingly also on this list.

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
(let's say to cover some of the Xquery usecases) please also suggest them to
jsr-283-comments@jcp.org and they will be considered by the expert group.

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 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. I think
this will be a feature differentiator between content repository vendors.
I am convinced that the Jackrabbit community will continue to provide
one of the most flexible implementations also with respect to the features
of the index (and therefore the query languages).

Please let's keep this discussion going since this is very important feedback
for the JSR-283 Expert Group.


View raw message