Re: target selector again

jamsden@us.ibm.com
Wed, 6 Oct 1999 08:44:29 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256802.004602B4.00@d54mta03.raleigh.ibm.com>
Date: Wed, 6 Oct 1999 08:44:29 -0400
Subject: RE: target selector again



<jra>
I agree with Jeff that we have some problems here. I doesn't make sense to
support versioned collections and versioned resources, while at the same time
having a Target-Selector that can only reference a label or id for a
non-collection resource. We either need to require workspaces only, or provide
overriding revision selectors for all components of a resource path. Requiring
workspaces only would be restrictive to clients that want to use workspaces as
checkout tokens, and may be overkill for servers that don't support versioned
collections, or users that don't use them. Specifying a path of revision
selectors has always been a problem because it either required us to introduce
mangled URLs or revision selector paths in the Target-Selector that are
separated from the resource path segments. How do other systems handle this?
</jra>





Jeff_McAffer@oti.com (Jeff McAffer OTT) on 10/05/99 06:38:12 PM

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

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.
>
>
>