Stefan L�tzkendorf <[EMAIL PROTECTED]> writes: > Eric Johnson wrote: > > My take is that displayname is a "live" server property, not a dead > > one, though. > > > That means, as I read it, that it is up to the server to do whatever > > the heck it wants with it. > > > The "default" value of the display name would seem to be the name of > > the file decoded from the URL into standard Unicode (and then > > re-encoded into the proper character set for XML). On a MOVE, then, > > if the destination indicates a new file name for the last portion of > > the URL at the destination, then having a "displayname" using the > > name at the old location seems _really_ odd to me. > > That's right. If the server maintains the display name, it should maintain > it while copy/move too. > > > If you want a "displayname" that has the properties you describe - > > that is, it doesn't change on move/copy - why not just add a dead > > property to the resource in question that is specific to your > > application? > > I don't use displayname as description. But the RFC does. > The point I want to say was that clients should not use displayname to > build uri's.
A summary from Lisa Dusseaults book [ISBN 0-13-065208-3, page 165]: The displayname was introduced to allow a name, which is friendly to the user, especially to allow non-ASCII characters, which may not be allowed on the server. displayname is a live property so the server can set it to any value it likes. Most servers (exchange, IIS, Xythos) will tie the displayname to the last URL segment. The user is not allowed to change it. If the resource is moved/copied the displayname will change. This is legal according to the words in the RFC but not the intended use. Apache mod_webdav sets the displayname to the empty string unless the client sets it explicit. If the resource is moved/copied the displayname will be copied too. This is a legal behavior too. However the differences in behavior mean, that the display name is not very useful to clients. Slides behavior is somewhere in the middle. The displayname is initially set to the last segment of the URL. The user is allowed to change it. The displayname is not changed on copy. IMHO this behavior is legal either but its problematic. Most clients handle a empty displayname gratefully by displaying the last URL segment instead. But most don't know how to display two different resources with the same displayname. On the other hand allowing the client to change the displayname and silently drop it on copy is not a good practice either. >From a usability point of view the best solution would be check, if the displayname already exists in this collection. Change it to value(2) only if there is already a resource with this displayname in the collection. However I am not convinced that it is worth the performance penalty for every move/copy. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
