- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sun, 4 Aug 2002 14:11:52 -0400
- To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
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. 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. I'm not convinced: the set of bindings of a resource is *not* a quality of the resource -- it's a quality of the collections that contain them. Computing all binds can be *very* expensive (for instance and AFAIK, in a plain old Unix filesystem you'll have to traverse the full namespace to find all bindings). I agree that bindings are part of the state of the collection, not part of the state of the resource, but there are many live properties that are used to report on relationships to other resources. There are also other live properties that are expensive to compute. But it is sufficient to require that such properties be explicitly requested (as is the case for all RFC-3253 properties), so that the client can control whether or not they want to pay the cost of this computation. Cheers, Geoff
Received on Sunday, 4 August 2002 14:12:35 UTC