W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: Question on GULP - properties defined as lockable, and content of a resource

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 29 Dec 2005 20:08:36 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF2432E463.B628A827-ON852570E7.0006293B-852570E7.00064825@us.ibm.com>
This rewording is fine with me.

Cheers,
Geoff

Lisa wrote on 12/29/2005 06:35:36 PM:

> 
> Looking carefully at the text of GULP from 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> 0177.html>:
> 
> - If a request would modify the content for a locked resource, a dead
>     property of a locked resource, a live property that is defined to be
>     lockable for a locked resource, or an internal member URI of a
>     locked collection, the request MUST fail unless the lock-token for
>     that lock is submitted in the request.  An internal member URI
>     of a collection is considered to be modified if it is added,
>     removed, or identifies a different resource.
> 
> 
> I see two problems with this paragraph
>   - The content of a resource is not defined anywhere.  Should this be 
> rewritten as "any variant" in order to consistently use RFC2616 
> terminology?
>   - The phrase "a live property that is defined to be lockable" implies 
> that we define properties to be lockable, but we don't.  Any 
> suggestions for fixing this?
> 
> One simplifying possibility is that if the request would modify *any* 
> live property, the lock token is required.  However I'm concerned that 
> there are some calculated live properties for which that would be 
> undesirable.  For example, if a resource had a live property called 
> "last-copied-to", and a COPY of that locked resource to some other 
> location caused the server to change the value of that live property to 
> the copy destination, then we wouldn't want to require the lock-token 
> of the source just because of that live property.
> 
> As a strawman, here's a proposed rewrite of the para, including minor 
> rewording/rearrangement for readability:
> 
>     "A lock-token must be submitted in a request if that request would
>     modify any of the following aspects of a locked resource:
>      - any variant,
>    - any dead property,
>    - any live property (unless otherwise specified for that property),
>    - for a collection, an internal member URI.
>     An internal member URI of a collection is considered to be modified
>     if it is added, removed, or identifies a different resource."
> 
> Lisa
> 
> 
Received on Friday, 30 December 2005 01:08:11 GMT

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