- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 22 Jan 2000 14:54:13 -0500
- To: w3c-dist-auth@w3.org
From: Randall Severy <severy@cyberteams.com> It's also a big issue when you're dealing with resources from something other than a simple filesystem. It's very risky to assume that the URL always refers to a filename that is meaningful to the user. I don't think anyone is assuming that the URL always refers to a filename. The real question is under what circumstances the URL cannot be made meaningful to the user. In a common authoring scenario, the author selects a collection, and then does a PUT, COPY, MOVE, MKCOL, MKRESOURCE, or whatever, to create a new member of that collection. It doesn't matter whether the resource is implemented as a file, a database record, or whatever. For example, our WebSite Director DAV interface supports DAV access to our workflow processing. The URL for an update request in a workflow stage would be something like "/WSD/Editing/requestB18894", which of course would be virtually meaningless to users. What WebDAV protocol do you use to create a new update request? There currently is no "create a resource and assign it whatever name you want" request. The versioning protocol has introduced a couple of methods like that to create specific versioning metadata resources, but normally resources contain the URL assigned to them by the user. The displayname property however, will be set to something like "ADD /mydir/myfile.html" or "MOVE /mydir/myfile.html TO /otherdir/myfile.html", which *will* be meaningful to users. Because of the fact that Web Folders ignores the displayname property, we're having to do some seriously ugly URL mangling to make our DAV interface even modestly useable. By ugly URL mangling, do you mean making the last segment of the URL be the displayname? Why is this a problem (other than the internationalization issues that Jim mentioned, and perhaps concern about the length of the URL)? Cheers, Geoff
Received on Saturday, 22 January 2000 14:54:15 UTC