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 [EMAIL PROTECTED] 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. regards, david
