RE: Bindings

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Friday, August 02, 2002 5:52 AM
> To: 'Webdav WG (E-mail)'
> Subject: RE: Bindings
>
> ..
>
>    However, from an abstract point of view, multiple URIs can identify
>    the same resource even if they live on separate HTTP servers.
>    In particular, the implementations wouldn't even know about the
>    "other" URI, and it would be impossible require both servers to
>    return the same DAV:resourceid.
>
> The only way the same resource could live on separate HTTP servers
> would be if the resource is immutable, or unless one server is
> intimately linked to the other (so that all changes made through one
> server to that resource are automatically available when accessing
> the resource from the other server).  In either case, the server
> would be able to return the same DAV:resourceid.

(see separate answer).

>    Seems we need better terminology here.
>
> Which terms do you think need to be replaced?

I think "same resource" only works when using it in a very technical sense.
It won't when using it in the generic sense when identifying abstract
concepts.

>    Furthermore, a particular user may not have the right to see all
>    URI mappings, and that kind of information is hard to marshall
>    inside a live property. I think this should be modernized to use an
>    explicit REPORT instead.
>
> If a client wants to retrieve this information, they should be able to
> batch up that request with other live property information, and should
> be able to use functionality like the DAV:expand-property report to
> thread through it.  Like other live properties with sensitive
> information (such as DAV:acl or DAV:version-history), the server will
> omit DAV:binding information for clients that are not permitted to see
> it.  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

Another one: why have the report DAV:locate-by-history if a
DAV:version-controlled-resource-set property would offer the same
information?

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

Received on Friday, 2 August 2002 03:52:58 UTC