Re: target selector again & again

Chris Kaler (ckaler@Exchange.Microsoft.com)
Thu, 7 Oct 1999 09:55:37 -0700 

Message-ID: <FD7A762E588AD211A7BC00805FFEA54B041DD94A@HYDRANT>
From: "Chris Kaler (Exchange)" <ckaler@Exchange.Microsoft.com>
To: "'Tim_Ellison@oti.com'" <Tim_Ellison@oti.com>, ietf-dav-versioning@w3.org
Date: Thu, 7 Oct 1999 09:55:37 -0700 
Subject: RE: target selector again & again


The idea was this, you get the history resource's href and the 
revision id.  Assuming that the server supports property 
collections, then the history resource will have a sub-resource
named the same as the revision id.  

However, I still believe that the server should be allowed to
support whatever naming strategy it wants and that property
resources are optional. :-)

Chris

-----Original Message-----
From: Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
Sent: Thursday, October 07, 1999 6:47 AM
To: ietf-dav-versioning@w3.org
Subject: RE: target selector again & again



<chris> Sorry, but "ick" :-)... </chris>

<tpe> I'm so glad you said that! </tpe>

<geoff>
     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).
</geoff>

<tpe>
Strange that the DAV:history would contain a resource, not a reference to a 
resource.  See further comments below.
</tpe>

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

<tpe> i.e.

PROPFIND myresource
<propfind>
   <prop>
      <dav:history/>
      <dav:revision-id/>
   </prop>
</propfind>

</tpe>

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

<tpe>
Now this is where it gets surreal :-)
The history property contains an XML representation of a history resource 
that has a revisions property.  This makes the revisions property a 
pseudo-prop (since it cannot be singularly retrieved by a PROPFIND; it is 
embeddd in a dav property).
A client always has to retrieve the entire history resource even if it only 
wants a single part of it.
Is this right?
</tpe>