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

RE: CHECKIN / CHECKOUT proposal from Geoff

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 15 Jun 2001 23:00:24 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B10350A8DC@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: John Hall [mailto:johnhall@evergo.net]

   > From Geoff Clemm
   > Add a property to a working resource like 
   > "DAV:checked-out-VCR".  Set this property on the working 
   > resource created when a CHECKOUT is applied to a VCR with the 
   > DAV:apply-to-version option.  A client is of course free to 
   > add/delete/change this property.  Then add a postcondition to 
   > "CHECKIN" that says that if there is a DAV:checked-out-VCR on 
   > the working resource being checked in, the specified VCR will 
   > automatically be updated to reflect the content and dead 
   > properties of that version.

   I think something like this would be highly desireable.  ...

   As I understand it then, the language goes something like this:
   DAV:apply-to-version  -- If this property is present, a CHECKOUT of a
   WORKING COPY on the VCR will set the property checked-out-VCR on the
   working copy.

Probably more like: "If DAV:apply-to-version is specified in the
request body, then the DAV:checked-out-VCR property of the working
resource created by the request MUST contain a DAV:href that contains
the request-URL.

   An implementation MAY support this feature.

I'd make it a MUST, unless someone can make a convincing argument
for why it is prohibitively difficult for some servers to support this
when they support the working resource feature.

   implementation MAY allow this property to be changed.

I'd make that a MUST as well.  Every MAY in the spec indicates
a failure to reach agreement, and represents an increase in the
complexity of writing an interoperable client.

   An implementation
   that supports this property, the feature WORKING COPY, but not the
   features UPDATE or MERGE, SHOULD prevent this property from being

I see no reason for this constraint (SHOULD's are only slightly
better than MAY's).

   <!ELEMENT apply-to-version EMPTY>

Yes (this is already a defined element in the protocol).


   If this optional property exists on a working copy, then a CHECKIN will
   also update the VCR listed.  An implementation MUST support this
   property if it supports WORKING COPY but not one of (UPDATE, MERGE).

As above, I'd make it a required part of the working resource
feature, not conditional on the non-support of some other feature.

   <!ELEMENT checked-out-VCR (href)>

   CHECKIN postcondition:

   If the property checked-out-VCR is present, then a CHECKIN will
   automatically update the VCR to reflect the content and dead properties
   of this version.


Received on Friday, 15 June 2001 22:55:17 UTC

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