Re: GULP as pure model

Lisa Dusseault wrote:
> 
> 
> On Jan 16, 2006, at 8:40 AM, Julian Reschke wrote:
> 
>> Lisa Dusseault wrote:
>> >
>> > This is an attempt to rewrite GULP purely as a model for inclusion in
>> > the introductory section of RFC2518bis. Mostly that meant rewording
>> > requirements in terms of statements about the model.  Also recall a
>> > couple weeks ago I brought up a couple wording issues with GULP -- 
>> these
>> > are addressed here too. Another notable change is that the last point
>> > (from the last version of GULP) was moved to #3, as I thought
>> > "conflicting lock" was a required concept before discussing how a new
>> > member of a locked collection may have a conflicting lock.
>>
>> Two general comments:
>>
>> - I think removing the normative language after all is a bad idea; it 
>> means that specs defined on top of WebDAV that add new methods can not 
>> simply ignore locking and delegate it to the base spec.
> 
> I don't follow this line of argument.  Do you mean an extension spec 
> like bind or advanced collection or quota, or a spec that obsoletes this 
> spec? How does this follow?

The former. For instance, take ACL. If the model language is normative, 
all ACL needs to define is whether the ACL properties are lockable.

>> > 7.  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).
>> >   In addition, the lock-token must be submitted if the request-URI
>> >   mapping changes to another resource or to no resource (e.g. DELETE).
>> >
>> > 8. If a request causes the lock-root of any lock to become an
>> >    unmapped URL, then the lock is also deleted by that request.
>>
>> I think I prefer the previous language, because it keeps things 
>> together that belong together (last part of 7 and 8):
>>
>> - If a request causes a directly locked resource to no longer be
>>     mapped to the lock-root of that lock, then the request MUST
>>     fail unless the lock-token for that lock is submitted in the
>>     request.  If the request succeeds, then that lock MUST have been
>>     deleted by that request.
> 
> I see #7 as being about "what actions require the lock token to be 
> submitted" and #8 about "what happens when a lockroot is deleted".  It 
> happens that deleting a locked resource is one of those actions that 
> require the lock token to be submitted so that certainly belongs in #7. 
>  I could phrase the item more clearly to be completely inclusive of all 
> the cases.

OK, I'll check then...

Best regards, Julian

Received on Monday, 16 January 2006 17:53:36 UTC