- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 9 Mar 2003 15:08:30 -0500
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
- Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F28@SUS-MA1IT01>
It occurs to me that the meaning of "modifying an internal member URI of a collection" might be unclear. So I suggest we add the explanation: "An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource." Here's a modified version of GULP with that addition. Cheers, Geoff -------------- - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - 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. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock, or when it appears in an untagged list and the request-URL is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. --------------
Received on Sunday, 9 March 2003 15:08:38 UTC