AW: new auto-version value

Hello Geoff,

 

The state machine was our initial motivation for this new auto-version property. Yes you are right the explicit check-in will
change the state, but return in the initial state again.

 

From the standard point of view we could argue that this new value would have for http and WebDAV clients the same post-condition,
namely the resource is kept checked-out. We would not tied together unlock and implicit checkin.

 

Anyway, there seems to be more points not to add it to the standard, than adding it to the standard. 

 


Best regards

Juergen Pill
Premium WebDAV Consultancy and Services 
www.webdav.info

  _____  

Von: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] Im Auftrag von Geoffrey M Clemm
Gesendet: Sonntag, 20. Juni 2004 04:55
An: w3c-dist-auth@w3.org
Betreff: Re: new auto-version value

 


This new auto-version value only makes sense if the "checkin" 
operation is used to promote a change in the workflow.  This is 
probably non-optimal, since it doesn't let a client save an 
intermediate state of the resource in the version history 
(i.e. before it is ready to publish).  In addition, a step 
in the workflow often requires changing multiple resources, 
so you can't really infer from one being checked-in that the 
task is complete.  So I would be against encouraging this 
model in the standard (and therefore would not 
be in favor of standardizing on this new value). 

WRT Lisa's question, he doesn't want the user to have to go to 
the external state-manipulation tool to start a modification, 
but he does expect the user to have to go to the external 
state-manipulation tool to say "I'm finished with this task". 
I agree that this is reasonable, but I'm against standardizing 
on "checkin" to mean "I'm finished with this task". 

Cheers, 
Geoff 

Lisa wrote on 06/18/2004 10:56:31 AM:
> I'm a little confused.  If you don't want the user to have to go to the 
> external state-manipulation tool, then why not use 
> checkout-unlock-checkin?  I would think you would want the checkin to 
> happen when editing is done, to publish the state.  Also note that the 
> state is "published" regardless, in that any changes made by any client 
> are visible on the resource checked out, whether or not it's checked in 
> again -- it seems pretty clear in this case you're talking about 
> in-place checkout.
> 
> The auto-version property is a bit of a hack to deal with 
> non-DeltaV-aware clients that can never know when to check out and 
> check in.  Adding more values to this property runs a risk of confusing 
> DeltaV clients that are aware of this property but only know the values 
> in the initial standard.  OTOH I'm not aware of any clients at all that 
> use the value of this property as yet so it would be good to hear if 
> there are any.

> On Jun 18, 2004, at 6:14 AM, Juergen wrote:
> > the auto-version property can currently hold 5 different values: 
> > Empty, checkout-checkin, checkout-unlock-checkin, checkout and
> > locked-checkout.
> >
> > I would like to propose a new value, named something like: 
> > checkout-ignore-unlock. It will carry the same semantics as the
> > checkout value, but an unlock command will not issue an implicit 
> > check-in command, instead the resource stays in the checked-out
> > state and an explicit check-in command is required.
> >
> > Use-case:
> >
> > A document is controlled by a workflow process. Creating a document 
> > takes this document in the initial-author state, in which only
> > explicit check-in command should create new versions. If this newly 
> > created resource is implicitly put under version-control and
> > the auto-version property is set to the new suggested value, we can 
> > receive this behaviour. Now the document can be modified
> > either with an http client (via put) or with a WebDAV client (Lock - 
> > Put* - Unlock) and still the resource is never implicitly
> > checked-in.
> > The same effect could be reached by an explicit check-out, but this 
> > will require an additional user interaction to issue the
> > check-out command, which we do not want to expose. Our user is then 
> > only required to use our state manipulation GUI tool, in case
> > of a real state change. The creation and manipulation of a new 
> > resource will feel like modification on the hard disc: create it,
> > modify it (with any tool) and then publish or change the state with an 
> > additional tool.
> >
> > Does this make a more general sense, or would you think this is a too 
> > specific requirement to go into any new version of the
> > delta-v standard?