Re: target selector again

Jeff McAffer OTT (Jeff_McAffer@oti.com)
Tue, 05 Oct 1999 18:38:12 -0400 

From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Oct05.183300.1250.1342848@otismtp.ott.oti.com>
Date: Tue, 05 Oct 1999 18:38:12 -0400
Subject: RE: target selector again


<jm>
This is still causing general distress.  It seems like the   
Target-Selector is doing double duty.  In one case (when its a workspace)   
we are saying that it is the one and only workspace to use to find the   
resource revisions.  In the other cases it seems to be used to help   
identify the revision of the resource for the last segment of the   
Request-URI.  In the latter case, any resource revisions not found in the   
thing identified by the Target-Selector causes the server to look in the   
default workspace.

Unfortunately, there are likely a large number of users for how the   
default workspace is uninteresting and the story becomes inconsistent.   
 If a client has her own workspace, falling back on the default workspace   
is unlikely to identify any of the resources/revisions in which she is   
interested.

It seems like the Target-Selector should be split into two parts (or,   
dare I say it, two headers) - one for the workspaces to use and the other   
for the config, activity, revision-id, ...  This would be clearer and   
more consistent.

To be completely honest, I have lost sight somewhat of what problems are   
solved by having non-workspace values of the Target-Selector.  I didn't   
realize that "no support for versioned-collections" was a valid DeltaV   
"mode" (refering to gmc's comments) below).  I can understand activities   
and configs etc but only when I can also talk about a backing workspace   
since these structures are not necessarily complete namespaces (i.e.,   
from root).
</jm>


>    <jm>
>    Here's a more fundamental question for clarification.
>
>    Is the Target-Selector intended to only be used when
> processing the last
>    segment of the Request-URI?
>
> <gmc/> Good catch, Jeff!  Yes, the DAV:revision-id was
> intended to apply
> only to the resource identified by the last segment of the
> URL, with the
> default workspace used to identify collection revisions (if any).
>
> <gmc/> Note that the DAV:rsr-revision-id selector is primarily for
> clients and servers that do not support versioned collections.  This
> is a special case, but an important special case since core versioning
> does not require versioned collections.
>
>    If the answer is yes, then specing a revision-id makes
> sense but how do I
>
>    specify the workspace in which I should find all of the
> parents and allow
>
>    me to get to the resource of interest (i.e., the last
> segment)?  Default
>    worksapce?  any activities?
>
> <gmc/> The default workspace.  I'll add this to the spec.
>
>    If the answer is no, specifying a revision-id is pretty
> bogus I am unable
>
>    then to spec the selection of the resource's parents.  How
> are they
>    selected?
>
> <gmc/> I agree (which is why the answer needs to be "yes" :-).
>
>    I vote that revision-ids are not valid Target-Selectors.
>
> <gmc/> They provide an easy way for a simple core versioning
> client/server
> to select an arbitrary revision.  I believe that's an
> important use case
> for us to support.
>
>    Follow on question.  If I spec a Target-Selector (say a
> configuration)
>    and the resource is not found in that scope, does the
> server return 404
>    or does it use the default workspace to continue the search?
>    </jm>
>
> <gmc/> Definitely a 404.  We should make this clear in the protocol.
>
>
>