FW: target selector again & again
Tim Ellison OTT (Tim_Ellison@oti.com)
Tue, 12 Oct 1999 10:07:56 -0400
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Oct12.100400.1250.1349016@otismtp.ott.oti.com>
Date: Tue, 12 Oct 1999 10:07:56 -0400
Subject: FW: target selector again & again
I dissented from accepting the two header field proposal during the
teleconference.
My position is eloquently stated by Jim A. below.
Tim
----------
From: jamsden
To: ietf-dav-versioning
Subject: Re: target selector again & again
Date: Wednesday, October 06, 1999 11:03AM
Tim raises a very interesting issue. In non-versioning servers, the URL is
mapped to the resource. In versioning systems, extra information is required
to select the applicable revision. This has to be provided on a
resource-by-resource basis, just like the URL. So any place there is a URL,
we must provide a context in which a revision of a versioned resource that
URL maps to is selected. In the case of URLs in documents, relative URLs
inherit the versioning context of the containing document, so there's no
problem there. However, there is with PROPFIND, PROPPATCH, MOVE, COPY, etc.,
all methods that reference more than one resource. If the revision selector
is not specified, the default workspace is used, so this is easy, and
supports non-versioning clients.
However, if a revision selector does have to be specified, then we must be
able to specify one for each participating resource. For PROPFIND and
PROPPATCH, we can extend the href element to include a workspace or other
revision selector. However, for MOVE and COPY, and other methods where the
URL is communicated in a header, there is no convenient way to include the
revision selector.
Looks like separating the revision selector from the URL is a continuing
problem. We're trying to specify an accessor for a revision in multiple
parts where some marshalling mechanisms don't support specifying both parts,
or the parts can't be associated with path elements.
Workspaces work well, but overriding the workspace with specific revision
selectors, or using workspaces as checkout tokens, without mangling the URL
continue to be problems.
---------------------------------
Tim_Ellison@oti.com (Tim Ellison OTT) on 10/06/99 10:21:04 AM
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
cc:
Subject: target selector again & again
Some DAV methods require a source and target URI (COPY, MOVE, BIND, REPORT,
etc).
In such methods I propose that the Target-Selector applies to the resolution
of both source and target URIs equally.
If a user should want to REPORT on different revisions of a versioned
resource, for example, they must specify at least one of the URIs as a
revision URI (i.e. through the history resource, as per a previous posting).
i.e.
REPORT /collection1 HTTP/1.1
Target-Selector: http://foo.com/workspace/mywksp
...
<D:compare-request>
<href>http://foo.com/history/collection1/42</href>
</D:compare-request>
...
means compare the revision of /collection1 selected by 'mywksp' with
revisionid:42 of the same collection.
Tim