hi julian
Julian Reschke wrote:
- DeltaVResourceImpl: compliance class should from my point of view
also mention the Label feature
Angela, please keep in mind that the Label *header* is deprecated,
please do not implement it (see <http://www.webdav.org/deltav/>).
but that's a different story isn't it? i was talking about the
compliance class (and the method set).
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)
[...]"
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?
kind regards
angela
