jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Wed, 18 Jul 2007 07:50:19 GMT

>> the entire industry moving towards XML data interoperability ...
> MSWord save document as XML file

I was just not sure what you meant with 'entire industry'. I agree XML
is important for document processing (however I would have probably
used JSON). But in my view, most data is still accessed using SQL or
directly from the file system.

> Full implementation would be too much, so subsets is the way to go.

I think it would be great to define the exact subset of XQuery!

> B.t.w. I integrated Saxon XQuery 1.0 engine into JCR 1.2.

How does this work, does it convert XQuery to XPath?

> >> But I strongly believe that AQM is a bad choice.
> Because re-inventing the wheel again

Sorry, for me it doesn't look like re-inventing the wheel. AQM is not
a language.

> XPath

For me, XPath was always quite complicated. I would probably get used
to it, but I prefer more verbose languages.

> * AQM - design to work with JCR Object model and so has limited functionality

What functionality are you missing?

> To summarize all this I propose to use 'X' languages to work
> with 'X' data structures.

So in your view, JCR is an XML database? For me, JCR is:
- File System
- Subversion

> Just swap Derby with eXist ....

So you suggest the Jackrabbit persistence should be an XML database?
And you would remove support for RDBMS / file system persistence /
Lucene? Wouldn't that be quite a big change and restriction?


View raw message