Subject: Question on GULP - resources added to locked collection

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Dec 2005 15:14:23 -0800

Looking closely at the text of GULP, point the third (from  
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
0177.html>):

"- If a collection is directly locked by a depth:infinity lock, all
    members of that collection (other than the collection itself) are
    indirectly locked by that lock.  In particular, if an internal
    member resource is added to a collection that is locked by a
    depth:infinity lock, and if the resource is not locked by that lock,
    then the resource becomes indirectly locked by that lock.
    Conversely, if a resource is indirectly locked with a depth:infinity
    lock, and if the result of deleting an internal member URI is that
    the resource is no longer a member of the collection that is
    directly locked by that lock, then the resource is no longer locked
    by that lock."

The part that confuses me is "if the resource is not locked by that  
lock".  I am not sure how that can be the case, and if it can never  
happen, then the clause should be removed from the sentence.  Even if  
it can happen, I think the sentence is even more true without that  
clause:

    "In particular, if an internal member resource is added to
    a collection that is locked by a depth:infinity lock,
    then the resource becomes indirectly locked by that lock."

Is that correct?

Thanks,
Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 29 Dec 2005 18:25:46 -0500

The current text handles the case where the directly locked
collection is being added as an internal member of a collection
that is a member of that directly locked collection.

In this case, the resource is already locked (so it does not
"become locked"), and it is directly locked (so it does not
"become indirectly locked").

Your proposed change does not handle this case.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Dec 2005 15:46:59 -0800

So an example of this occurring is a COPY of a locked collection to a 
location inside the locked collection ( to make a copy inside itself).  
  Still, doesn't the new member become indirectly locked?  It's not the 
same resource as the original locked collection.  Since it's not the 
same resource, I disagree with your point -- I think it's still 
accurate to say that the new member (the copy) becomes indirectly 
locked.

Perhaps another tenet of our locking model is that a copy of a locked 
resource does not create a new lock, nor is it directly or indirectly 
locked by the original lock, unless the original locked resource is a 
collection and the copy destination is a member of that locked 
collection.

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 29 Dec 2005 20:18:18 -0500

> accurate to say that the new member (the copy) becomes indirectly 

No, this is not an example, because as you point out, this
creates a new resource, which becomes indirectly locked.

An example of this is a BIND of the locked collection to a location
inside the locked collection.  Another example is when there are
two URL's that are mapped to the locked collection, and you issue
a MOVE request on the URL that is not the lock-root, with a
Destination that is a member of the locked collection.

> collection and the copy destination is a member of that locked 

That is true, but it follows from the fact that the lock is associated
with the request-URL of the LOCK (i.e., the lock-root).  So I wouldn't
state this as part of GULP, since it is redundant (although I wouldn't
object if something like this were added to some discursive text
elsewhere in the locking section).

Cheers,
Geoff