Julian Reschke wrote:
Bertrand Delacretaz wrote:
...
So I think the JSR 283 approach, which is IIUC:
1. Specify a realistically implementable query model
2. Specify a default language, SQLish so that most people understand
it well
"SQLish" language are not capable to work with graph like structures that JCR
offers, and has no knowledge of Nodes and Properties that are core JCR data model.
So let's be real, while it is still possible to calculate 2 x 2 using abacus
working with anything more advanced almost impossible.
We should understand that each tool has it's boundaries.
Actually, it was essential. All the SQL and XQuery based proposals IMHO
were lacking a precise underlying definition -- after all, the JCR data
model is neither precisely XML/Infoset, nor relational. The Query Model
provides that, it's (hopefully) a precise statement about the query
capabilities of a JCR 2.0 store should support.
Let me disagree with you, JCR data model are not relational for sure.
And it is more like an extended XML model, operates with Nodes and Properties
with an exception that a single node may have more that 1 parent.
So applying SQL language that design to work with relational model to advanced
XML model is a mistake.
Requiring full XQuery support would have been a problem because it
essentially would have increased the complexity to implement JCR to be
*bigger* than XQuery; basically making it an XML database + versioning +
observation + locking + versioning + transient space.
Let me repeat myself again:
XML DB offers out of the box:
Transactions
Locking
Triggers, observers
Spaces (logical)
Access control
Management interface
PLUS some that JR does not have
Hot backup/restore
Better clustering
Better performance
So as you can see by putting JCR on top of XML DB you REDUCE amount of work.
You just left with versioning to implement ....
Please let's be reasonable, I am offering to streamline development process, and
deliver results faster than AQM get polished.
Defining a subset still would have been
problematic: you need to agree on *what* subset, and there'd still be
lots of mapping issues to resolve (binary properties, element names....).
No need to define any subsets, just integrate with eXist/BerkeleyXMLDB/Tamino,
etc.. and you have XQuery 1.0 XPath 2.0
I want to stress out that by dropping XPath and not introducing XQuery JCR has
nothing to offer except versioning in comparison with XML DB, that will be the
good choice to build home-grown Content Repository.
And it has been proven a few time, even a few days ago:
[Subject: Jackrabbit is dead (for us)]
I'm sorry to inform you that we did not select Jackrabbit as the CMS of the
platform we're currently developing (well designing right now).
[Subject: Jackrabbit is dead (for us)]
[David Nuescheler reply]
I am convinced that improving Jackrabbit (keep in mind, this is an
Opensource project) could cover your needs much quicker than, building
your own repository from scratch.
[/David Nuescheler reply]
As you can see JCR does not offer anything that can't be replaced in reasonable
amount of time.
--
Ivan Latysh
[EMAIL PROTECTED]
