RE: Bindings

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff

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

   Wel, it requires additional parameters *because* it's a report. It
   wouldn't, if a live property would have been chosen instead...

The fact that a version-tree request requires more than a URL (i.e. it
also needs the list of properties to be retrieved) is not affected by
how we marshall the request.  How would you marshall as a PROPFIND a
request that wants the MYPROP:foo and MYPROP:bar properties of every
version in the version tree?  You have to put the "MYPROP:foo" and
"MYPROP:bar" information somewhere, and there is nowhere to put it in
a standard PROPFIND request.

   >    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?).

No, this is just because you need at least two values: the URL for the
folder in which to look for the VCR, and the URL for the version
history that you are looking for.   The fact that you are allowed to
look for several version histories in one request is irrelevant (but
since you asked, this is usually an expensive operation which can be
optimized if the server can use one pass to look for all the version
histories that you are interested in).

   My point being -- the border between live properties and REPORTs
   isn't nearly as well defined as you say.

Simple well-defined rule: If you only need to specify a URL and a
(constant, standard) property-name in the request, it is a live
property.  If you need more than that, it is a report.

Cheers,
Geoff

Received on Friday, 9 August 2002 17:16:48 UTC