Re: target selector again & again

Geoffrey M. Clemm (gclemm@atria.com)
Wed, 6 Oct 1999 17:47:28 -0400 

Date: Wed, 6 Oct 1999 17:47:28 -0400
From: gclemm@atria.com (Geoffrey M. Clemm)
Message-Id: <9910062147.AA15133@tantalum>
To: ietf-dav-versioning@w3.org
Subject: RE: target selector again & again

The current protocol (02.2) specifies that a revision resource has a
DAV:history property (a property resource) containing the history resource
for that revision, and a history resource has a DAV:revisions property
(a property collection) that contains all revisions of that versioned
resource (named by their revision-id's).

I believe this gives the servers the flexibility that they need
to define the location of these collections, while giving clients an easy way
to obtain the name of the collection.

In particular, if we define the "XML" form of DAV:history property resource
suitably, a client will be able to obtain the revision URL
in a single PROPFIND request on the versioned resource.  In particular, the
DAV:revision-id will contain the revision id (reasonably enough :-), and
the XML form of the DAV:history property would contain the DAV:revisions
property (whose value is the name of the
revisions collection).  The client can then just concatenate the DAV:revisions
value with a slash and the DAV:revision-id to get the revision URL.

Cheers,
Geoff


> -----Original Message-----
> From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
> Sent: Wednesday, October 06, 1999 2:04 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: target selector again & again
> 
> 
> 
> <sarge>
>      So precisely how do you get the revision's URL?
>      Assuming you normally use the versioned resource's
>      URL you have to query to discover the revision's URL
>      (or the history URL and the revision-id).  This is not a new
>      problem, but I don't immediately see how it's done with
>      the current protocol.
> </sarge>
> 
> <tpe>
> How about this:
>      1) PROPFIND myresource -> DAV:history-uuid
>      2) PROPFIND myresource -> DAV:revision-id
>      3) some random call to find out where in the namespace the server 
> creates history resources; maybe OPTIONS myresource??
>      4) the URL is 
> http://foo.com/<history_place>/<history_uuid>/<revision-id>
> 
> Problems:
>      a) it's three calls to the server to deduce this fundamental 
> information,
>      b) step (3) has not ben defined, indeed there are suggestions that the 
> server should not dictate this information.
> </tpe>
>