GULP (Version 5.5)

Here's a new version of GULP, with the following changes:
- adjust wording to allow for a LOCK to request to just refresh
 an existing lock
- allow any mention of a lock token in an If header to be a
 "submission" of that lock token.
I believe this covers the specific issues raised by Lisa,
except for:
"Finally, this stuff doesn't address what happens to the other 
bindings of a locked resource - if they now appear as locked, 
which I would assume." 
I assume by "this stuff", Lisa is referring to the GULP specification.
Since I believe the current GULP text covers all of the cases
introduced by multiple bindings to the same resource, I'd need
a specific situation which is not covered by the current GULP
text before this can be considered a real issue.
WRT to Lisa's assumption (the other bindings are locked),
as Julian indicated, according to GULP that is incorrect,
i.e. only the mappings specified by the request-URL of
the LOCK are locked by the LOCK request.
Note: The GULP specification does not enumerate all of the
resources and bindings that are NOT affected by a LOCK request,
because there are an infinite number of these. If a resource
or binding is not identified as being affected by the LOCK,
it is not affected by the LOCK.
Cheers,
Geoff
-------------- GULP (Version 5.5) --------------
- A lock either directly or indirectly locks a resource.
- When 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.
- 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 Monday, 29 December 2003 23:10:01 UTC

AltStyle によって変換されたページ (->オリジナル) /