Next message: Clemm, Geoff: "RE: Naive question"
From: Tim_Ellison@uk.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <80256959.004AE045.00@d06mta07.portsmouth.uk.ibm.com>
Date: Wed, 13 Sep 2000 14:37:35 +0100
Subject: Working resource locations
I'm puzzled by the language used in the 10.2 CHECKOUT postconditions, which
states that "...the server MAY locate the working resource at the
request-URL, effectively replacing the version selector...".
(1) If the server choses to replace the version selector, it would seem
that that is not a good idea since CHECKIN will delete the working
resource, and the resource at the other end of the request URI will
disappear. That seems like a strange side effect of editing something.
Maybe CHECKIN replaces the working resource with a version selector again
that targets the new revision, but that is not stated or implied anywhere.
(2) If the server chooses not to replace the version selector with the
working resource then clearly it must put the working resource elsewhere
and the version selector remains at the other end of the request URI. I
didn't see any property that links the working resource to its version
selector or vice versa.
In the second of 10.3 CHECKIN preconditions the doc. states "If the version
selector is write-locked..." -- what version selector? This is the first
reference to a version selector in the description of CHECKIN (the second
is in the postconditions). Am I correct in assuming that the version
selector somehow remembers that it produced a working resource and
operations on the working resource it produced can have an effect back on
the selector?
(3) Note that in the description of 10.4 UNCHECKOUT the preconditions
simply refer to "...the appropriate lock token..." so that did not help to
clarify the situation.
Tim