- From: Jim Davis <jdavis@parc.xerox.com>
- Date: Wed, 2 Sep 1998 08:45:49 PDT
- 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 requirements >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.). regards Jim
Received on Wednesday, 2 September 1998 12:48:31 UTC