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

RE: auto-version

From: Eric Sedlar <Eric.Sedlar@oracle.com>
Date: Thu, 11 Jan 2001 15:24:27 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <NDBBLFOFMCKOOMBDHDBKCEONCAAA.Eric.Sedlar@oracle.com>
I mostly object to replacing "true" with <DAV:true>.  I don't have
a problem with changing auto-version in particular to an extensible
type as long as you don't make "true" and "false" some of the values
of this (now) nonboolean field.

--Eric

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Geoffrey M.
> Clemm
> Sent: Thursday, January 11, 2001 3:14 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: auto-version
> 
> 
> 
>    From: "Eric Sedlar" <Eric.Sedlar@oracle.com>
> 
>    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")
> 
> Yes the proposal is to change the datatype from boolean to an
> extensible type (but I think we'd call the new value
> "DAV:checkout-when-locked" as opposed to "IBM:it-depends" :-).
> 
> So do you object to replacing "true" with </DAV:true> (which you are
> supposed to have forgotten about, because it was so obviously wrong
> and I'm embarassed I ever brought it up :-), or object to allowing
> multiple values in DAV:auto-version (which I think is probably OK)?
> 
> Cheers,
> Geoff
> 
>    > -----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 18:27:57 GMT

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