Re: Question on GULP - resources added to locked collection

Lisa Dusseault <lisa@osafoundation.org> wrote on 12/29/2005 06:46:59 PM:

> 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.

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.

> 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.

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


 
> On Dec 29, 2005, at 3:25 PM, Geoffrey M Clemm wrote:
>
> > 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.
> >
> > Lisa wrote on 12/29/2005 06:14:23 PM:
> >
> >  >
> >  > 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