Next message: Geoffrey M. Clemm: "Re: Naive question"
Date: Wed, 13 Sep 2000 23:54:09 -0400 (EDT)
Message-Id: <200009140354.XAA07595@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: Tim_Ellison@uk.ibm.com
CC: ietf-dav-versioning@w3.org
Subject: Re: Working resource locations
From: Tim_Ellison@uk.ibm.com
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...".
That language is there to make sure that clients are prepared to
deal with workspace behavior.
(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.
Good point. I'll add this to the CHECKIN description (it is in
the advanced versioning CHECKIN description, but it needs to appear
in the core versioning description as well).
(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.
Another good point. A DAV:version-selector property on a working
resource seems appropriate in this case. This also lets us address
your first point more directly, by saying in CHECKIN that "if the
working resource has no DAV:version-selector property (because it was
checked out in-place), it is replaced by a version selector whose target
is the new version".
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?
Actually, that was a cut/paste error. It should have said "if the
working resource is write-locked ...". I'll fix that.
(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.
I'll modify that to say "if the working resource is locked".
Cheers,
Geoff