Bindings, was: Issue: URI_URL, proposed changes

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Wednesday, July 31, 2002 2:02 PM
> To: 'Webdav WG (E-mail)'
> Subject: RE: Issue: URI_URL, proposed changes
>
> ...
>
> I also believe that it would be valuable to have a standard
> property that identifies a URN for a resource, and that is
> one goal of the binding spec (which we should be able to finish
> up as soon as we have the ACL spec wrapped up).  In particular,
> the binding spec introduces the DAV:urn property for this purpose.
>
> I wouldn't want the DAV:source property confused with the DAV:urn
> property.

I'm not sure how the DAV:source property relates to bindings, but this is
certainly a good opportunity to discuss some open issues with the BIND spec.
I read some of the discussion from winter 2000 on the mailing list (just
after submission of the 02 draft... [1]), and I'll try to summarize the main
open points...

1) It seems to me that there is agreement on what a BIND is, and how the
presence of multiple bindings to the same resource affects DELETE.

2) As some recent discussion in the deltav mailing list showed, we already
have situations where additional bindings are created as side effects of
versioning operations. As a matter of fact, just because the BIND spec
wasn't finished doesn't mean that there aren't already shipping WebDAV
implementations that have to deal with bindings -- we're just lacking
standardized methods to explicitly create them / to get additional
information about them.

3) There was a disagreement about whether BIND should be applied (a) to the
collection in which the mapping is to be created or (b) to a URI of the
resource that should get the additional binding. Roy prefers (preferred)
(a), and I think technically he's right. The WG prefers (preferred) (b),
because that's consistent with COPY/MOVE. As a server implementor, I'd
prefer (a) because it seems cleaner.

4) There was a violent disagreement whether there needs to be a mechanism to
retrieve a globally unique identifier for the resource (which is not
supposed to change once the resource is created). The current spec calls
this DAV:resourceid, Geoff mentioned DAV:urn (drafts and memory out of
sync?).

The issue here seems to be that "identity" of a resource is hard to define.

Looking from an implementators POV, a resource in a document repository
certainly has identity defined by a row number in a database or an inode
number in the file system (for instance). With this piece of information, a
server can easily assign persistent URIs to these objects that survive
renaming. Having this information available can help a client keeping it's
caches consistent (it would know that an operation that affects one resource
will affect all resources with the same DAV:resourceid as well). I'd like to
understand whether somebody thinks that this is a problem (would that make
that an optional feature, or would it have to be removed?)?

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.

Seems we need better terminology here.

5) The spec defines a live property (DAV:bindings) that contains a list of a
URI mappings to a resource. From a marshalling perspective, that's a bad
thing. It can be expensive to compute (so we would have to enforce RFC3253
propfind/allprop behaviour). 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.


Julian


[1]
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/thread.html#12
5>

Received on Thursday, 1 August 2002 03:43:34 UTC