Re: target selector again
Jeff McAffer OTT (Jeff_McAffer@oti.com)
Tue, 05 Oct 1999 13:03:20 -0400
From: Jeff_McAffer@oti.com (Jeff McAffer OTT)
To: ietf-dav-versioning@w3.org (ietf-dav-versioning)
Message-ID: <1999Oct05.125900.1250.1342242@otismtp.ott.oti.com>
Date: Tue, 05 Oct 1999 13:03:20 -0400
Subject: RE: target selector again
<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?
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?
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?
I vote that revision-ids are not valid Target-Selectors.
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>
> -----Original Message-----
> From: jamsden [mailto:jamsden@us.ibm.com]
> Sent: Tuesday, October 05, 1999 11:08 AM
> To: Jeff McAffer (OTT)
> Cc: ietf-dav-versioning
> Subject: Re: target selector again
>
> Maybe the Target-Selector should be a RSR, i.e., a list of
> revision selectors.
> We also talked about a "path of revision selectors" to
> specify the revision
> selector for each element in the URL path. All this was to
> avoid mangling the
> URL with things like http://host:8080/foo@2/bat@33/index.htm@25.
>
> We may also want to associate a context with a user that
> could include his
> workspace, current activitiy, etc. This is effectively what
> "local mode" does.
> But this is becoming pretty stateful. If the collections
> aren't versioned,
> then
> there is no issue though.
<jm>Yikes! this is alot of work/complexity. I vote no.</jm>