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

RE: multiple parents (Was 'last call' comment on draft-ietf-webdav-protocol-07.txt-- resource:URL 1:1?)

From: Jim Davis <jdavis@parc.xerox.com>
Date: Wed, 2 Sep 1998 08:45:49 PDT
Message-Id: <>
To: <w3c-dist-auth@w3.org>
At 08:33 PM 9/1/98 PDT, Larry Masinter wrote:
>The concern is that protocol-07, as written, doesn't allow interoperable
>implementation with a server that employs aliasing, and makes some
>on servers that wind up being (false) assumptions that clients will make

I'm not sure I agree there's a problem that needs fixing.  For one thing,
since no one ever wrote a 'requirements document' for any  Web server that
does aliasing, we don't know what the intended abstraction is, and hence
can't tell whether WebDAV is breaking it.

I can think of at least four possible intentions:

1 - a resource has one "true" URL, and may have additional synonyms.
Deletion using the true name deletes the resource.  Future references using
the synonyms return an error.  An attempt to delete using a synonym has no
effect. (since there's no means in the protocol to create a synonym, why
should there be one to remove it?)

2 - Same as 1, except that deletion of a synonym removes that name from the
namespace but has no effect on other names.  This is like the semantics of
a Unix symbolic link.

3 - All names are equally valid.  Deleting a resource under any of its
names deletes it for all of them.

4 - All names are equally valid, but the resource only disappears when the
last name is deleted.  This is like Unix hard links.

Does anyone have any insight as to which was the intended purpose of
aliasing?  Were the others considered and rejected for some reason?

>I think that it's simple to fix the protocol by adding a "parent" property

I'm not so sure it's simple.  I suggest you try it yourself, then send the
appropriate language to the list.  For one thing, should it be parent,
singular, or parent, plural?  If you want it to be singular, then you are
introducing some concept of a "true" URL with the others being second-class.

For another, I would claim that if you wanted this at all, what you'd want
would be a property whose value was the set of all names by which the
resource could be located (ie. the synonyms).  Given this you can find the
set of parents trivially (by chopping the last component off).  But given
the parents only, you can't easily find the names.  This property is in
fact _exactly_ what I proposed as the "references" property in recent mail
apropos ACR.  It must of course be optional, as some servers will be
disinclined to support it.

As for the four semantics above, the ACR proposal provides semantics #2.

Why?  Because it does all that #1 does, plus more.  #3 is dreadful, as it
allows anyone who can link to a resource to also delete it.  #4 is not as
bad as #3, but I think many people like the idea of having full control
over resources (they want to be sure they can really delete something and
have it be gone.).


Received on Wednesday, 2 September 1998 12:48:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC