Subject: Re: Should I use displayname?

From: [email-masked]
Date: Wed, 19 Jan 2000 13:04:41 -0500

When I'm trying to perform a directory browsing, that I'm going to present
to a user. Should I then present the Displayname info or should I pars the
href to get the name of the resource, from the Propfind request?
If I should use the Displayname info, can I rely on that it only contains
the name of the resource and not the complete path? ( this seems to be the
case for IIS, Xythos, Zope. But not for CyberTeams server )
Noone has answered, so I will take a stab.

I don't think you can count on it containing anything and even that it
exists.  If it does exist, it does seem like the thing you'd want to
display.

Note: I don't think it's even technically required to correspond to
the URI at all.

Note: in the presence of multiple bindings, if the server initializes it
to the URI and treats it as a dead property, that URI might be different
from the URI from which it was accessed.  This unexpected behavior is even
possible (but less likely) if the value is only initialized to the last
segment of the URI.

That's only the technical answer.  If you were asking for a consensus
answer, you can add DAV4J to the list.  It currently treats it as a dead
property that gets initialized to the full URI.  It also allows the client
to change the displayname to anything they wish.

---

From: Greg Stein <[email-masked]>
Date: Wed, 19 Jan 2000 15:07:03 -0800 (PST)

On Wed, 19 Jan 2000 [email-masked] wrote:
>...

As another point of reference:

mod_dav treats it as a dead property and does *not* initialize the value
to anything. In other words, it (typically) does not exist on a resource.
If it does, then it only contains whatever somebody happened to shove into
it -- that could be a JPEG image for all mod_dav cares.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 20 Jan 2000 11:13:46 -0800

> it -- that could be a JPEG image for all mod_dav cares.

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.

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.

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.

Since client behavior is currently closer to case (1), this might be the
best plan for moving forward.

- Jim

---

From: Jim Whitehead <[email-masked]>
Date: Fri, 21 Jan 2000 09:49:46 -0800

Jason writes:
> from the URI from which it was accessed.

Hmm, since properties are part of the state of the resource, in the presence
of bindings it is more than possible for there to be multiple URI names for
the same "display name".  This removes the value of the displayname
property.  Some solutions:

1) move displayname to the collection, and have the collection maintain
displayname/binding pairs (this solution seems icky to me)

2) deprecate displayname, and only use URIs for display to the user, and
concentrate on i18n support for URIs.

- Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 21 Jan 2000 13:57:52 -0500

I vote for choice 2, since choice 1 is so egregiously bad.

Cheers,
Geoff

   From: Jim Whitehead <[email-masked]>
   Date: Fri, 21 Jan 2000 09:49:46 -0800
   Content-Length: 708

   - Jim

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 21 Jan 2000 15:49:53 -0800

I don't understand what the problem is.  The client can use the displayname
to store some user-interpretable name for a resource that is independent of
the binding, so that the user can tell that these two URLs apply to the same
resource (they probably won't look at resourceID).  For example, the client
could parse the <title> out of an HTML document and store it there.  If you
default the display name to the last segment of the URL, then things can get
confusing as you point out.  It's up to the client to do something useful
here.

--Eric