Next message: Geoffrey M. Clemm: "Re: Target-Selector"
From: Tim_Ellison@oti.com (Tim Ellison OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Dec24.094400.1250.1427650@otismtp.ott.oti.com>
Date: Fri, 24 Dec 1999 09:52:08 -0500
Subject: RE: Target-Selector
I'd really like to have both a Workspace: header and a Revision-Selector:
since it seems that a common operation, when dealing with history, is to
check-out a particular revision into a given workspace.
Presently, we only have a single selector that specifies the workspace to
both select the revision and contain the working resource. There is, for
example, no means of requesting a check-out of a labeled revision into a
named workspace -- and I think that will be a common requirement. The
solution at the moment is to PROPFIND the stable revision URL using the
label selector, then checkout with the workspace selector.
I think 'workspace' would be a good candidate for addition to the headers.
Here's my renditioning of a full-on selection:
CHECKOUT /colln1/colln2/foo,html HTTP/1.1
Target-Selector: label:Release1.0; finally label:bugfix
Workspace: http://www.wedav.org/myworkspace
which reads: checkout /colln1/colln2/foo.html by selecting the revision of
colln1 and colln2 labeled Release1.0 and the revision of bugfix labeled
foo.html into the workspace 'myworkspace'.
Tim
----------
>From: jamsden
>To: ietf-dav-versioning
>Subject: RE: Target-Selector
>Date: Wednesday, December 22, 1999 4:10PM
>
>How about sticking with separate headers as they are simpler and easier to
>parse than one. I suggest headers that reflect the roles the values are
>playing rather than their types. For example, Revision-Selector for the,
>well, revision selector, and Override-Selector for the leaf if the revision
>selector is being overridden. This is the same as Geoff's proposal, but it
>keeps the notion of Workspace out of the Revision-Selector so we could
>potentially use other things there like a label, configuration, revision
>id, activity, etc.
>
>
>
>
>
>Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/22/99 02:06:36 PM
>
>Sent by: ietf-dav-versioning-request@w3.org
>
>
>To: ietf-dav-versioning@w3.org ('Delta V')
>cc:
>
>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
>
>
>
>
>
>
>