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
makes a lot of sense.
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.
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. Good luck in
getting vendor support for that. 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....).
It doesn't prevent implementations from defining additional query
languages, and maybe those could come later as extensions or
additional specs?
So although I will miss XPath, I agree that it's a good thing for the
spec to concentrate on the underlying query model.
I'll assume Jackrabbit users will not have to miss XPath, as it's going
to stay available. That being said, I personally think that XPath
support should *not* be optional in JCR 2.0, if only for the sake of
backwards compatibility.
The spec now is in public review, so please speak up!
Best regards, Julian
