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.

   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