W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: AW: new auto-version value

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Mon, 21 Jun 2004 08:23:34 -0700
Message-Id: <F5E2E859-C396-11D8-A549-000A95B2BB72@osafoundation.org>
Cc: WebDAV <w3c-dist-auth@w3.org>
To: <webdav-standards@webdav.info>

Would another separate property work as well, or better?  A 'publish' 
property for manual setting, or an 'auto-publish' property indicating 
when the server should try to publish?  You might find support for that 
kind of thing orthogonal from versioning.

Lisa


On Jun 21, 2004, at 3:15 AM, <webdav-standards@webdav.info> wrote:

> 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?
>
Received on Monday, 21 June 2004 11:23:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT