W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Legal operations on members of a Baseline Collection...

From: Peter Raymond <Peter.Raymond@merant.com>
Date: Fri, 28 Sep 2001 09:28:36 +0100
Message-ID: <20CF1CE11441D411919C0008C7C5A13B02969D78@stalmail.eu.merant.com>
To: "Clemm, Geoff" <gclemm@rational.com>, ietf-dav-versioning@w3.org

Still seems odd that text buried in the definition of a property of 
a baseline version is defining the behaviour of methods on the members of
a baseline collection.  But the "MUST have" change is certainly an 

A better solution would be to add the definition of the Baseline Collection 
to section 10.2 (Advanced Versioning Terms, we currently define
"Baseline Resource", "Baseline-Controlled Collection" etc, but it does not
"Baseline Collection".  I guess there is no room for this definition, I
think it 
would solve all my issues with baseline collections:

Baseline Collection

A Baseline Collection captures the state of the baseline-controlled 
collection at the time the baseline was created.  Particularly, for 
each version-controlled resource in the configuration rooted at the 
baseline-controlled collection a new version-controlled resource will 
be created in the baseline collection that MUST have the same 
DAV:checked-in version and relative name.  Any collections needed to
create a consistent copy of the configuration namespace should also be 

This collection cannot be modified except by checking-out and 
checking-in a version-controlled configuration.  At most one member 
of this collection can have a DAV:checked-in version from a given 
version history.

I like the definition because it makes it clear that a Baseline Collection
captures not only version-controlled resources (as the current specification
incorrectly hints) but that it also captures any collections needed to get
those VCRs (in the namespace).  It also makes it clear that the baseline
collection should not be modified in any way except when version-controlled
configurations are checked-out and checked-in.

Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
WWW: http://www.merant.com

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 27 September 2001 17:54
To: ietf-dav-versioning@w3.org
Subject: RE: Legal operations on members of a Baseline Collection...

Yes, we normally prefer to define constraints in the form of preconditions,
but in this case, the single statement "must never change" in the property
definition was so much simpler that repeating it in each "mutating" method.
But I agree that this normative aspect of the property
definition should be highlighted.  I suggest we change the "has" to a
"MUST have" in the definition to make this point (a change that fits the
"no-repagination" goal :-).


-----Original Message-----
From: Peter Raymond [mailto:Peter.Raymond@merant.com]
Sent: Thursday, September 27, 2001 11:16 AM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: RE: Legal operations on members of a Baseline Collection...

OK...I guess that section does make it clear. 
But, how much of the normative text should be captured in pre and post 
conditions? Without any pre or post condition to enforce the paragraph 
that you quoted do vendors have to obey that paragraph? 
Would I am getting at is that other areas where we are enforcing something 
we explicitly enforce it using pre or post conditions.  But not this one. 
Received on Friday, 28 September 2001 04:30:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC