W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Bindings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 10 Aug 2002 10:25:46 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, "'Webdav WG \(E-mail\)'" <w3c-dist-auth@w3c.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEPAFBAA.julian.reschke@gmx.de>

> 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC