- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 9 Aug 2002 21:12:01 +0200
- To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG \(E-mail\)'" <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Sunday, August 04, 2002 8:12 PM > To: 'Webdav WG (E-mail)' > Subject: RE: Bindings > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Reports should be only used when parameters are required for the > > request, and DAV:binding is not a parameterized request. > > RFC3253 counter example: DAV:version-tree report -- could have been > replaced using a DAV:version-set report and the DAV:expand-property > report > > The DAV:version-tree report requires additional parameters (in > particular, the list of properties to be retrieved). It therefore > must be a report, not a live property. It is true that the > DAV:version-tree report could be handled by a DAV:expand-property > report, but that doesn't affect the fact that the DAV:version-tree > report requires additional parameters, which is why it is a report and > not a live property. Wel, it requires additional parameters *because* it's a report. It wouldn't, if a live property would have been chosen instead... > Another one: why have the report DAV:locate-by-history if a > DAV:version-controlled-resource-set property would offer the same > information? > > The DAV:locate-by-history report requires additional parameters > (namely, the list of version history resources that are to be located > in the folder identified by the request-URL). Therefore it cannot be > a live property, but must be a report. This is just because the marshalling was defined to specifically to lookup by by multiple VHRs (by the way: what's the use case for that?). My point being -- the border between live properties and REPORTs isn't nearly as well defined as you say. > ...
Received on Friday, 9 August 2002 15:12:34 UTC