Re: target selector again & again
Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 6 Oct 1999 12:56:19 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF5343881@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: "'Tim_Ellison@oti.com'" <Tim_Ellison@oti.com>, ietf-dav-versioning@w3.org
Date: Wed, 6 Oct 1999 12:56:19 -0700
Subject: RE: target selector again & again
I also like the idea of treating the history resource as a collection so
that we have a defined pattern for assigning URLs to revisions that is
intuitive.
Using this approach you would (almost) never use the revision-id for a
target selector in a copy operation (for example). Instead you would use
the revision's URL (which you would have to know), or a label, or a
workspace. So precisely how do you get the revision's URL? Assuming you
normally use the versioned resource's URL you have to query to discover the
revision's URL (or the history URL and the revision-id). This is not a new
problem, but I don't immediately see how it's done with the current
protocol.
--Sarge
-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Wednesday, October 06, 1999 7:21 AM
To: ietf-dav-versioning@w3.org
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