Re: Question on GULP - resources added to locked collection

So in the case of a locked collection bound to an internal member of 
itself, the locked collection is both directly locked and indirectly 
locked.

Is the text *still* ok though?  In the case of the collection being 
bound to a child URL of itself, the collection still becomes indirectly 
locked, right?  (Just not to the exclusion of being also directly 
locked).   Here's the proposed text again:

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

We may want to add the principle that in the presence of bindings a 
resource may be both directly and indirectly locked (though personally 
I'd prefer the bindings spec to say that).

Then of course, there's the possibility for an infinitely locked 
collection to contain a member URL that binds to a resource that is 
locked by a *different* lock.  Because of the model of only the binding 
that was locked being protected, it seems that other bindings could be 
added to the locked collection but the resource would not become 
indirectly locked.  E.g. if A is locked with lockA, and B is locked 
with lockB, and B' is an unlocked binding to the locked resource also 
bound to B, then if B' is moved into A, the resource under B' cannot 
become indirectly locked with lockA.

Is this text correct then?

"In particular, if an internal member resource is added to a collection 
that is locked by a depth:infinity lock (and if the new member resource 
is not already locked by any lock), then the resource becomes 
indirectly locked by that lock."

Seems that this kind of text goes beyond almost any implementation of 
RFC2518 (only servers implementing bindings would need to worry about 
the nuances we're discussing) and is quite confusing without examples.

Lisa

On Dec 29, 2005, at 5:18 PM, Geoffrey M Clemm wrote:

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