Date: Sat, 23 Oct 1999 17:35:41 -0400 Message-Id: <9910232135.AA23948@tantalum> From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org In-Reply-To: <1999Oct07.094400.1250.1344836@otismtp.ott.oti.com> Subject: Re: target selector again & again From: Tim_Ellison@oti.com (Tim Ellison OTT) <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> You have to tell PROPFIND which property resource to expand, and which properties of that property resource to display: PROPFIND myresource <propfind> <prop> <dav:expand-property-resource> <dav:versioned-resource/> <dav:revisions/> </dav:expand-property-resource> </prop> </propfind> <tpe> Now this is where it gets surreal :-) But in a good way (:-). The history property contains an XML representation of a history resource that has a revisions property. Actually, the versioned-resource property (AKA the history property) contains an href to the versioned resource, but that you can ask PROPFIND to recurse into the resource named by that href. In this case, you're asking it to return the DAV: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). It can be retrieved either way, so it's more of a "super-prop" than a "pseudo-prop" (:-). A client always has to retrieve the entire history resource even if it only wants a single part of it. Is this right? </tpe> Not if it uses the <dav:expand-property-resource> element in a PROPFIND request. It's at this point that one of my colleagues at work is known to remark "you just made that up, didn't you". But no really, I made this up a while ago ... notice the <dav:expand-property-resource> mentioned in the 02 spec (:-). Cheers, Geoff