Jukka Zitting wrote:
I'm not free to discuss the specifics of the discussions leading to
this decision, but the query features have certainly been one of the
more debated areas of the specification. There are a number of
conflicting requirements from various vendors and users, and it was
felt that specifying an abstract query model instead of a specific
query syntax would better allow us to express the specific query
functionality that a content repository needs to implement.
I would like to see the AQM use-case that can't be expressed in XQuery ?
The point is that I do not see the reason to introduce AQM as intermediate query
language when XQuery is more powerful, well defined and natively fit JCR model.
Note that Jackrabbit will most certainly continue to support XPath and
our plan is actually to implement an XPath/XQuery to JCR query model
converter, that should be usable by any JCR 2.0 repository or client
to support queries expressed in (a subset of) XPath or XQuery.
XPath is out of the spec, it does not matter if JR support it or not.
B.t.w. make no sense to write XQuery -> AQM transformer, because it will hit the
wall very fast. On the other hand AQM -> XQuery transformer is much easier to
write and will have more features.
As I sad before XQuery is much more powerful than AQM. Unless AQM will replicate
XQuery, if it does, what is the point of re-inventing the wheel ?
Also I am confused why committee dropping XPath support when the entire industry
moving towards XML data interoperability ...
Please let us know at [EMAIL PROTECTED] Direct user feedback
is very valuable, especially since most of the expert group members
represent the repository implementer and vendor point of view.
Yes I will.
--
Ivan Latysh
[EMAIL PROTECTED]
