RE: Bindings

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, August 09, 2002 11:16 PM
> To: 'Webdav WG (E-mail)'
> Subject: 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.

I wouldn't marshall it as PROPFIND. I would use the DAV:expand-property
REPORT.

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

OK, so why isn't it good enough to search for *all* VCRs (no matter which
collection they are in)?

> 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 Saturday, 10 August 2002 04:26:14 UTC