Re: target selector again & again

jamsden@us.ibm.com
Wed, 6 Oct 1999 10:59:07 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256802.00525D0D.00@d54mta03.raleigh.ibm.com>
Date: Wed, 6 Oct 1999 10:59:07 -0400
Subject: Re: target selector again & again



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