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

Re: auto-version

From: Greg Stein <gstein@lyra.org>
Date: Thu, 11 Jan 2001 12:07:51 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010111120751.I4640@lyra.org>
On Thu, Jan 11, 2001 at 09:56:30AM -0500, Clemm, Geoff wrote:
> Good points.  I'll fix that up.
> 
> While I'm in there, Jim Amsden asked if we could add a
> value to DAV:auto-version that says "only auto version
> while locked" (i.e. this would say to auto-checkout if
> the checked-in vcr is write-locked, but just fail the
> update if it is not write-locked).
> 
> I think this is a decision more likely to made by the
> server (i.e. does it have an efficient delta scheme for
> that resource type), but I'd be happy to add this if 
> folks think it's a good idea.  Any preference?

It should not be added. I don't have locking in my server, so adding that to
the spec would mean that I couldn't ever auto-version.

What the heck does locking have to do with auto-version? If a person does a
PUT, then you spin off a new version. Requiring it to be locked is a policy
decision.

> This brings to mind another point ... currently we have
> a couple of properties that take string values of "true"
> and "false".  It occurs to me that it would be cleaner to
> have elements called "DAV:true" and "DAV:false".  Any
> objections to this change?

Yes. :-)

We used "true" and "false" to follow the values from the XML Data stuff
(IIRC). We shouldn't go and monkey them to use something else.

And it isn't like we need namespace protection for these.

Cheers,
-g

> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]
> Sent: Thursday, January 11, 2001 9:21 AM
> To: ietf-dav-versioning@w3.org
> Subject: DAV:auto-version
> 
> 
> 
> 
> >From versioning-11
> 
> 2.2.5 DAV:auto-version
> 
> When the DAV:auto-version property of a checked-out version-controlled
> resource is set, a modification request (such as PUT/PROPPATCH) is
> automatically preceded by a checkout operation.
> 
> (1) Oops, I think that should be referring to a checked-in VCR.
> 
> (2) If I was going to be pedantic I would say that the property should be
> set, and its value should be 'true' .
> 
> (3) We seem to have lost the description of 'doing no harm' during
> modification failures (words to te effect that if the PUT fails the server
> should be left as though non of the CHECKOUT-PUT-CHECKIN sequence
> occurred).
> 
> 
> Regards,
> 
> Tim Ellison
> Java Technology Centre, MP146
> IBM UK Laboratory, Hursley Park, Winchester, UK.
> tel: +44 (0)1962 819872  internal: 249872  MOBx: 270452

-- 
Greg Stein, http://www.lyra.org/
Received on Thursday, 11 January 2001 15:07:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT