jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Wed, 18 Jul 2007 08:57:24 GMT
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

View raw message