Re: Target-Selector
Tim Ellison OTT (Tim_Ellison@oti.com)
Wed, 22 Dec 1999 14:06:36 -0500
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org ('Delta V')
Message-ID: <1999Dec22.140400.1250.1425905@otismtp.ott.oti.com>
Date: Wed, 22 Dec 1999 14:06:36 -0500
Subject: RE: Target-Selector
I stand by my original proposal, although I agree we are only differing by
syntax.
Firstly, I would prefer not to have two headers simply because it promotes
header bloat (would that be Workspace:, Revision-Selector:,
Desination-Workspace: and Destination-Revision-Selector:?).
I find the name Target-Selector quite meaningful (as these things go :-) and
a finally clause more intuative than recognising the overriding nature of
Revision-Selector/Workspace headers.
Secondly, using 'keyword-space-value' is, as you would say, morally
equivalent to a URI. By specifying as URIs you have a natural forward
compatibility solution that you cannot otherwise guarantee.
.. and finally, having to specify "configuration" is redundant since the
server will have to ensure the following URL really is a configuration and
not another type.
So my objections are more on (relatively trivial) implementation grounds
than the semantics of our solution.
Tim
----------
From: Geoffrey M. Clemm
To: ietf-dav-versioning
Subject: Re: Target-Selector
Date: Wednesday, December 22, 1999 1:28PM
I'd like to propose a syntactic variant on Tim's proposal:
Instead of adding a "finally" clause to the Target-Selector header,
let's replace the "Target-Selector" header with a "Workspace" and a
"Revision-Selector" selector header. One advantage is that
Workspace and Revision-Selector are more self-explanatory than
Target-Selector.
A Workspace header specifies either a Workspace URL or nothing,
where nothing corresponds to the old "metadata" Target-Selector.
A Revision-Selector specifies a label, an id, or a configuration.
A Workspace header specifies target selection for the entire request.
A Revision-Selector header overrides the Workspace header for the
versioned resource identified by the Request-URL.
workspace-hdr = "Workspace" ":" [ URL ]
revision-selector-hdr = "Revision-Selector" ":" revision-selector
revision-selector = "id" segment
| "label" segment
| "configuration" URL
I'd like to keep the "id", "label" and "configuration" keywords
to avoid ambiguity in case we decide to extend those namespaces.
Cheers,
Geoff
From: Tim_Ellison@oti.com (Tim Ellison OTT)
I'd like to propose a change to the Target-Selector as described in the
protocol spec.
Presently, the valid values are:
workspace "<URI>"
id "<revision id>"
label "<label>"
metadata
The change would accomodate the situation where the client wants to
select
collection revisions using a workspace, and the final resource using a
label
or id. Without such a change the "id" target selector is of little/no
use
for selecting resources in collections (the collection will not have the
same id as the "leaf" resource).
The change would also allow the client to select a revision based
directly
upon an activity and provides extensibility for other selection schemes.
target selector = Target-Selector ":" URI [ LWS "; finally" URI ]
The use of URIs gives us extensibility for defining new selection
mechanisms, and the optional "finally" clause allows clients to specify a
different selector for the leaf. (I don't see any benefit for N
selection
methods.)
Example URIs would be id:some_id, label:some_label, metadata:, and
http://machine/resource where 'resource' is a workspace or activity or
something else (the server gets to figure out which by looking at the
resource type). Specifying a resource that cannot be used for selection
results in a bad request.
Example target selectors would be:
Target-Selector: http://foo.com/mywork
Target-Selector: http://foo.com/mywork ; finally id:Rev12FP
Target-Selector: label:bar ; finally http://foo.com/actif1
Comments?
Tim