- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Wed, 24 Nov 1999 11:46:06 -0500
- To: w3c-dist-auth@w3.org
X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 23 Nov 1999 23:26:13 +0100 From: Jim Davis <jrd3@alum.mit.edu> References: <LNBBKDGPNJMOJNOBHLLMGEAFCEAA.wiggs@xythos.com> Mime-Version: 1.0 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: <w3c-dist-auth@w3.org> archive/latest/3638 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Length: 1426 At 04:19 PM 11/23/99 -0500, Geoffrey M. Clemm wrote: > A write lock on a collection, whether created by a "Depth: 0" or "Depth: > infinity" lock request, prevents the addition or removal of member URIs of > the collection by non-lock owners. > If a lock owner causes the URI of a resource to be added as an internal > member URI of a locked collection then the new resource MUST be > automatically added to the lock. > >I believe this statement should only apply to non-Depth:0 locks. >Otherwise, this results in the inability to independently lock >a collection and members of the collection. How so? please provide a sequence of operations that would be impossible under this interpretation. I lock a collection, because I'm going to be adding members to that collection. If a depth:0 lock applies to all the immediate members of a collection as well, then I have prevented anyone from updating the state of one of the existing internal members of that collection. If I'd wanted that behavior, I would have issued a depth:1 lock. And quoting from the definition of what depth means: The Depth header is used with methods executed on resources which could potentially have internal members to indicate whether the method is to be applied only to the resource ("Depth: 0"), to the resource and its immediate children, ("Depth: 1"), or the resource and all its progeny ("Depth: infinity"). Cheers, Geoff
Received on Wednesday, 24 November 1999 11:46:09 UTC