David Nuescheler wrote:
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.
So you are saying that some vendors put stop on technological evolution in favor
of preserving their proprietary implementations ?!
If it is the case let's explain to the community that certain vendors would like
to sell their proprietary JCR based CMS so we change the spec to match their
implementation.
Let's be clear what JCR 2.0 is intend for.
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.
I believe that we were talking about the technology and not about an
implementation details.
But we can scratch implementation aspect as well.
Some facts:
To marry Saxon XQuery 1.0 engine with JCR 1.0 takes 1 day for an average
developer, it will be very inefficient but will work.
To build-in XQuery 1.0 + XPath 2.0 into JCR would take about 2-3 month of work
(top). Just swap Derby with eXist ....
(Note: I have no knowledge on how JR handle versioning so time estimate does not
include versioning migration)
SQL -> XQuery transformation is a trivial task. AQM -> XQuery is easy as well.
But XQuery -> AQM will have many limitations making it almost useless at the
end.
So I do not see any extensive issues to implement XQuery in JCR.
--
Ivan Latysh
[EMAIL PROTECTED]
