Re: Target-Selector

jamsden@us.ibm.com
Wed, 22 Dec 1999 13:55:17 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525684F.00687B91.00@d54mta03.raleigh.ibm.com>
Date: Wed, 22 Dec 1999 13:55:17 -0500
Subject: Re: Target-Selector



Geoff,
I like it. This looks a lot like what we discussed in DC. It separates the
workspace which is used for server calculated revision selection, and user
overrides.





"Geoffrey M. Clemm" <geoffrey.clemm@rational.com>@w3.org on 12/22/99
01:22:55 PM

Sent by:  ietf-dav-versioning-request@w3.org


To:   ietf-dav-versioning@w3.org
cc:

Subject:  Re: Target-Selector



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