Re: Target-Selector
jamsden@us.ibm.com
Wed, 22 Dec 1999 11:44:37 -0500
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525684F.0061A1BA.00@d54mta03.raleigh.ibm.com>
Date: Wed, 22 Dec 1999 11:44:37 -0500
Subject: Re: Target-Selector
Sounds reasonable.
Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/22/99 10:48:40 AM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org ('Delta V')
cc:
Subject: Target-Selector
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