Next message: Geoffrey M. Clemm: "Getting rid of "delete" semantics for checkout/checkin"
Date: Fri, 2 Jun 2000 21:31:27 -0400 (EDT)
Message-Id: <200006030131.VAA28899@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: LOCK and versioned resources
After making a pass through the protocol, I now believe that we need
to simplify versioning locking semantics. Earlier I had proposed that
a lock be on a combination of the locking URL, the Target-Selector header
value, and the Workspace header value.
This results in all sorts of complicated interactions between exclusive
and shared locks, depth locking, not to mention my favorite, lock null
resources. We would have to add elements to the lock discovery (e.g.
Target-Selector header value and Workspace header value), and define how
these elements interact.
I believe there is an easy simplification we can make, especially now that
we have URL's for all resources. This is just to say:
"A LOCK request cannot include either a Target-Selector or Workspace header."
You can still lock every resource, by using its URL. In fact, we probably
don't have to say anything about locking at all, other than the fact that
a LOCK/UNLOCK request cannot include these headers.
Cheers,
Geoff
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
The intention of a LOCK is to ensure that (1) the resource
content/properties and (2) request-URI/target-sector are protected by the
lock token owner.
So if we have a versioned collection (/foo/) and versioned data container
(/foo/bar), the effect of taking out a lock as follows:
LOCK /foo/bar
Target-Selector: tested
Workspace: http://whatever/mywksp
means that the target of the request should be protected in both ways
described above.
The implications are that:
(a) the default target for /foo/ in /mywksp cannot be changed (using
SET-TARGET),
(b) the binding /foo/ and /foo/bar cannot be changed (using MOVE/DELETE),
and (c) the label "tested" cannot be moved/removed from the revision it is
presently on (using LABEL).
I surprised myself with point (c) -- but I think this is what we want.
[Note that if the revision labeled "tested" is the default target for that
resource in /mywksp, and if I hadn't provided the Target-Selector:, then
point (c) would not apply (i.e., the label could be (re)moved)]
Comments?
Tim