Hi,
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
- RDBMS
- LDAP
- 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?
Thomas