Re: rfc2518bis-14: locking terminology

John Barone wrote:
> "Section 6.1 defines what a lock is. This is done by giving a set of 
> "axioms", propositions using the term 'lock' which are true by 
> convention. It should be possible to read the spec without the slightest 
> idea what a lock could be. Let us assume that we have no such idea and 
> read section 6.1. Then we have an understanding of what a lock is, but 
> we would be very surprised if someone spoke of 'moving locks'. We would 
> say something like: "Hey, wait, how can you move it if it does not even 
> have a location?".
> 
> If one thinks that it makes sense to move a lock, he simply has an 
> understanding of the term 'lock' that does not match the definitions in 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?"
>  
> [John] I still don't agree.  The basic question is if you copy a 
> resource has a lock, does the target resource have a lock (albeit with a 
> different lock-root).  The answer is "no" it doesn't, if the target is 
> not under a locked parent; that should be clearly stated somewhere.  
> Similarly a locked resource that is MOVED, does it still have a lock?  
> The answer here is also "no" it doesn't, if the target is not under a 
> locked parent; this should also be clearly stated somewhere.  Why not 
> clear up ambiguity with definitive statements?  Argue as you might, 
> clearly there are those who believe there is ambiguity, otherwise this 
> language wouldn't have been added.  BTW, this language, or something 
> similar was in the previous 2518 spec., and I don't see a compelling 
> reason to remove it now.
>  
> -John 
> 
> 

First of all, this part of my original mail was about _how_ things are 
stated, not _if_ they are stated.
There are some operations that can, by definition, be performed with a 
lock. You can create it. You can delete it. Section 6.1 defines what 
that means. But since it is not defined, you can't eat it, you can't 
take it around the block, and no, you can't move or copy it!

Second of all, when you COPY a resource A which is locked by the lock L, 
the destination resource B may of course also be locked by L, namely if 
it's a member resource of the resource which the lock root is mapped to. 
This follows immediately from 6.1.4.
So generally, after the COPY is performed, B may or may not be locked by L.

Regards,
Manfred


Regards,
Manfred

> 
> ------------------------------------------------------------------------
> *From:* Manfred Baedke [mailto:manfred.baedke@greenbytes.de]
> *Sent:* Thursday, March 16, 2006 10:25 AM
> *To:* John Barone
> *Cc:* w3c-dist-auth@w3.org
> *Subject:* Re: rfc2518bis-14: locking terminology
> 
> John Barone wrote:
>> "My main point here is the use of undefined terminology, though I 
>> indeed think that section 6.1 will be perfectly clear on the 
>> distinction between a depth 0 and a depth infinity lock as soon as 
>> 6.1.4 uses the term 'member' instead of 'internal member'. 7.4 
>> contains nothing new, and a list of special cases can never be as 
>> concise as the general principle itself. "
>>  
>> [John] OK, I can see that; however section 6.1.4 does not make the 
>> distinction between depth 0 and depth infinity locks.  This section 
>> needs to be cleaned up to make that distinction, and spell out the 
>> exact bahavior in both cases.  Maybe combining what's in section 7. 
>> bullet 2 and what's currently in section 6.1.4.
>>
> Agreed that section 6.1 should define lock depth.
>>  
>>  
>> [John] If the root of a lock is a collection, it's important to make clear
>> that that collection is locked, along with all it's decendents.  I think
>> this statement should stay (but perhaps reworded to be more precise).
>>  
>> My point here is that URIs cannot be locked. Resources can be locked, 
>> but the root of the lock is not a resource.
>>  
>> [John] If the target URI for a depth infinity lock request is a 
>> collection, the collection IS most certainly locked.  But to your 
>> point, if the language in section 6.1.x is cleaned up, this entire 
>> section can be removed.
>>
> The target URI of a lock request will never be a collection, but the URI 
> of a collection. An URI is an URI and a resource is a resource. As 
> defined in 6.1, resources can be locked. URIs can't.
>>  
>> Move/Copy behavior...
>>  
>> Well, copying locks is as undefined as lock duplication
>>
>> How could one think that a lock could be moved if it is not defined 
>> what this could mean?
>>  
>> ... by the same token, what does it mean to duplicate or move live or 
>> dead properties; those operations aren't defined either for 
>> properties, and yet you MUST/SHOULD do it.  I don't see the harm here, 
>> in fact I think it's a very good idea to explicitly state this in the 
>> spec. to remove ambiguity.  I think the copy/move MUST NOT statements 
>> should be kept either in a 7.x section, or wrapped into a revised 
>> 6.1.4 section.
> Well, if the spec does not define what it means to move a property, then 
> it should either correct this or stop to use this terminology.
> 
> Section 6.1 defines what a lock is. This is done by giving a set of 
> "axioms", propositions using the term 'lock' which are true by 
> convention. It should be possible to read the spec without the slightest 
> idea what a lock could be. Let us assume that we have no such idea and 
> read section 6.1. Then we have an understanding of what a lock is, but 
> we would be very surprised if someone spoke of 'moving locks'. We would 
> say something like: "Hey, wait, how can you move it if it does not even 
> have a location?".
> 
> If one thinks that it makes sense to move a lock, he simply has an 
> understanding of the term 'lock' that does not match the definitions in 
> this specification. If the specification never mentioned 'moving locks', 
> why would any reader think that this term even had a meaning?
> 
> Regards,
> Manfred
>

Received on Friday, 17 March 2006 09:00:33 UTC