RE: auto-version

I object.  You are implicitly changing the datatype of
a property from boolean to QName if you change it from allowing
"true" to "DAV:true".  Are you planning on allowing other
values in those fields (e.g. "IBM:it-depends")

--Eric

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Thursday, January 11, 2001 6:57 AM
> To: ietf-dav-versioning@w3.org
> Subject: RE: auto-version
>
>
> 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?
>
> 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?
>
> 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
>
>

Received on Thursday, 11 January 2001 11:52:52 UTC