Re: target selector again

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 6 Oct 1999 09:58:47 -0400 

Date: Wed, 6 Oct 1999 09:58:47 -0400
Message-Id: <9910061358.AA14793@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <1999Oct05.183300.1250.1342848@otismtp.ott.oti.com>
Subject: Re: target selector again


   From: Jeff_McAffer@oti.com (Jeff McAffer OTT)

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

<gmc/> Interesting.  I tend favor header minimization, but I
find your argument quite convincing.  In particular, a reasonable name
for the header for workspaces would be "Workspace" (pretty creative
of me, I know :-), and then "Target-Selector" could be the other one.

   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>

<gmc/>  One area where versioned collections are not needed are for
document management systems where the documents live in a flat namespace
and inter-document references are done with GUID's rather than URL's.
Another area is to make the protocol suitable for simple servers that
just want to dump leaf versions into an RCS file, and don't want to
track namespace changes.  In these cases, a simple selection of the
the revision-id of the leaf is quite sensible.

<gmc/> One sanity check that the two header approach satisfies is:
"Does it make sense to use both headers in one request".  I believe
the answer is yes, because even if you are using a workspace to
select all the versioned collection revisions, it still makes sense
to request particular revisions of the leaf versioned resource.
For example:

GET /x/y/foo.html
Workspace /dav/workspaces/geoff
Target-Selector <D:rsr-revision-id> r75 </D:rsr-revision-id>

could be used to select revision r75 of /x/y/foo.html instead of
the default one that /dav/workspaces/geoff would select.  The
version selection for /x and /x/y would be peformed by the workspace
revision selection rules.

With this approach, the absence of a Workspace header would clearly
indicate the desire to use the default workspace.

Cheers,
Geoff