jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From IvanLatysh <i...@yourmail.com>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Tue, 17 Jul 2007 19:58:15 GMT
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
ivan@yourmail.com

Mime
View raw message