Subject: RE: Should I use displayname?

From: Randall Severy <[email-masked]>
Date: Sat, 22 Jan 2000 12:05:12 -0500

At 11:13 AM 1/20/00 -0800, Jim Whitehead wrote:
>Well, the intent of the displayname property was to provide a mechanism by
>which a user could assign a more meaningful name to a resource other than
>just the URL.  In particular I was thinking about non-latin character sets
>(like Kanji), which are currently poorly handled by existing URLs.

Jim,

       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.  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.  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.

>However, this thread is certainly showing that there is an interoperability
>problem here. There are two choices:
>
>1) Have the server make it a dead property, initialized to be empty.
>Clients would display the last path segment from the href URL
>preferentially, but would display the displayname property if set.

I think it should be an option for servers to initialize the property to 
something meaningful to users, as in the example given above.  Also, 
clients should display the displayname property if set and only display the 
last part of the URL if there is no displayname property, again based on 
the example given above.

>2) Have the sever make it a dead property, initialized to the last path
>segment of the href URL.  The client would always use the displayname value.

This assumes that the last path segment of the href URL has any meaning to 
the user, which is often not the case when dealing with document 
repositories and other non-filesystem servers.

Cheers.......    Randall

Randall Severy    [email-masked]    http://www.cyberteams.com/severy
CyberTeams, Inc.    [email-masked]    http://www.cyberteams.com
Mt. Airy, MD
(301) 829-6144          "Building effective teams in cyberspace"
1-888-832-5575

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 22 Jan 2000 14:54:13 -0500

From: Randall Severy <[email-masked]>

	  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 

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

---

From: Randall Severy <[email-masked]>
Date: Sat, 22 Jan 2000 15:40:53 -0500

>a file, a database record, or whatever.

Geoff,

      My mistake.  As you picked up on, the key word I was referring to was 
"meaningful", not "filename".  What I should have asked is "isn't it risky 
to assume that the URL always represents something meaningful to the 
user?".  I would argue that the answer is Yes, in that the DAV server 
should be able to choose to use URLs that mean something to the internal 
representation of the objects but that are complete gibberish to the 
users.  Forcing the server to generate URLs that are meaningful to the user 
puts a severe limitation on server design, IMHO.

>but normally resources contain the URL assigned to them by the user.

      WebSite Director is a workflow/approval-based authoring system.  When 
you send PUT, MOVE, COPY, or DELETE methods to WebSite Director, the change 
is not immediately made to the filesystem, which would defeat the purpose 
of an approval system.  Instead, WebSite Director automatically creates an 
update request in the workflow system that matches the original DAV 
request.  Following the necessary approvals of that update request, the 
actual update to the web site takes place.  It is functionally equivalent 
to an FTP "incoming" directory, where a system administrator has to take 
some action to make an uploaded document visible and available to users by 
moving it out of the "incoming" directory.

       Consequently, WebSite Director assigns each new update request an 
internal identifier, which is used in the URL to refer to that pending 
update request (there's no point in using the original URL provided by the 
user since the update hasn't been published yet).  That URL is in the form 
mentioned previously, "/WSD/Editing/requestB18894", for example.

>about the length of the URL)?

      To be able to use Web Folders effectively with our workflow 
processing (since Web Folders doesn't do anything with the displayname 
property), we are adding functionality to mangle the URLs of update 
requests so that the above mentioned request would instead have a URL of:

/WSD/Editing/MOVE |mydir|myfile.html TO |otherdir|myfile.html

       To be able to handle DAV methods against the above object, WebSite 
Director has to convert that mangled URL back into the internal identifier 
to figure out what to do.  Just the simple fact that you can't include "/" 
characters in the "filename" component of a URL makes the above mangling 
very ugly.  We settled on the vertical bar ("|") character as the closest 
approximation that we can get away with, but it's still very ugly.  If, on 
the other hand, Web Folders (or any other DAV client) were to check for a 
displayname property, containing "MOVE /mydir/myfile.html TO 
/otherdir/myfile.html", for example, and display that to the user if it was 
found, it would work very smoothly for the client, the server, and the user.

Cheers......   Randall