Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.20 as permitted sender)
Message-ID: <469E134D.5080801@gmx.de>
Date: Wed, 18 Jul 2007 15:19:09 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the
 simple
 server
References: <24452978.1184754364919.JavaMail.jira@brutus>
 <469DED27.4050503@gmx.de> <469E0B59.9000302@day.com>
In-Reply-To: <469E0B59.9000302@day.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Angela Schreiber wrote:
> but that's a different story isn't it? i was talking about the
> compliance class (and the method set).

Probably. I just wanted to make sure that no time is spent on something 
that is broken in the spec...


>>> RFC 3253 defines a separate behaviour for version-controlled 
>>> collections.
> 
>> I'm not completely sure what the issue is? A version controlled 
>> collection is a specific type of a regular version controlled 
>> resource, it just also records information about version controlled 
>> children...
> 
> what i meant:
> 
> http://www.webdav.org/deltav/protocol/rfc3253.html#version-controlled-collection.feature 
> 
> states the following:
> 
> "As with any versionable resource, when a collection is put under 
> version control, a version history resource is created to contain 
> versions for that version-controlled collection. In order to preserve 
> standard versioning semantics (a version of a collection should not be 
> modifiable), a collection version only records information about the 
> version-controlled bindings of that collection.
> 
> In order to cleanly separate a modification to the namespace from a 
> modification to content or dead properties, a version of a collection 
> has no members, but instead records in its 
> DAV:version-controlled-binding-set property the binding name and version 
> history resource of each version-controlled internal member of that 
> collection.
> [...]
> 
> A version-controlled collection has all the properties of a collection 
> and of a version-controlled resource. In addition, the 
> version-controlled-collection feature introduces the following REQUIRED 
> property for a version-controlled collection.
> 
> 14.1.1 DAV:eclipsed-set (computed)
> [...]"

Clarifying: the difference between a collection and a non-collection 
with respect to WebDAV versioning is that the version-controlled state 
of a collection *additionally* includes the binding-set (for the 
members), but not the members itself.

> however: the patch provided by jeremi and modified by rob does
> not distinguish between collections and non-collection resources.
> in both cases the underlying repository Node is made 'versionable'.
> consequently both collections and non-collections behave the
> same way (i.e. like version-controlled resources), which is from my 
> understanding not what the RFC defines. see quote above.
> 
> do i miss something?

Hm, probably I'm partly confused because I've "grown up" with RFC3253 
semantics, and haven't used collection versioning in JCR so far (the 
system I currently work on only can version leaf files + properties).

It seems the counterpart of a version controlled collection in WebDAV 
would be a JCR node where all children have 
OnParentVersionAction=IGNORE, meaning they are always version-controlled 
independently of the parent. I'm not sure whether anything else can be 
exposed in a RCF3253 compliant way.

We may have to ask Geoff for advice :-).

Best regards, Julian