Re: auto-version

Good point. If it isn't boolean, then true/false shouldn't be used. In
short, the values could be:

  <DAV:allowed/>
  <DAV:not-allowed/>
  <DAV:must-be-locked/>

That would be quite fine. (along with retaining the notice that the server
may (protect) the property from being changed, and/or not allow changing it
to must-be-locked)

Cheers,
-g

On Thu, Jan 11, 2001 at 03:24:27PM -0800, Eric Sedlar wrote:
> 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
> >    >
> >    >
> > 
> > 

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 12 January 2001 07:15:41 UTC