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

Lisa Dusseault wrote:
> 
> 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."


That's ok, except for

a) we lost the MUST here (and this is a place where it's really needed), and

b) we then also have to think about which live properties defined in 
RFC2518bis are not lockable (note that it's probably wise to keep that 
terminology); DAV:lockdiscovery comes to mind.

Best regards, Julian

Received on Saturday, 31 December 2005 12:10:35 UTC