jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From IvanLatysh <i...@yourmail.com>
Subject Re: 7.4 Appendix D: JCR 1.0 XPath (Deprecated)
Date Wed, 18 Jul 2007 14:46:38 GMT
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
ivan@yourmail.com

Mime
View raw message