RE: response to comment ...

> > Now, as then, WFS sets the display name to be the base name from the
> > path part of the URL.  So for us resourcename is a property which is
> > constant as long as the resource's URL is constant, and 
> changes when the
> > URL changes.  I don't know if we'd change this if we did support
> > bindings.
> 
> Well, I consider this a bug. It's not supported by the spec.

I've always thought this was against the spirit of the WebDAV
specification. However, I don't think it can be considered a bug.
RFC2518 doesn't require displayname to have a particular value, or to be
writable, or to be empty.

> The Webfolder client indeed displays the displayname instead 
> of the last URI
> segment when present (and even uses in in the "href" column 
> instead of the
> real URI). This works well when
> 
> - the last part of the displayname consistently is identical 
> to the last URI segment (mod. URI escaping) (IIS)

Yeah, this is what WFS does, I believe we consciously mimicked IIS in
order to work well with Web Folders.

> - DAV:displayname is just a dead property that most of the 
> time isn't set (moddav)

Do you know what happens when it is set to some value other than the
last URI segment?  Does any client get confused when the URI ends in
"index.html" but the displayname shows "Index of files here"?

More interestingly, what happens if there are two resources in a
collection which have the same resourcename -- does this confuse the
client deeply?

> If we consider this an interop problem, we should deprecate 
> DAV:displayname
> (because that's the only way to "fix" the webfolder client) 
> and come up with
> a new property with the same semantics.

That might be cool. Exchange 2000 uses a "subject" property across many
types of resources (emails, appointments, maybe even Office documents)
to serve as a truly user-displayable value or "friendly name".  Its
value is not unique within a collection, so multiple emails in the same
folder can have the subject "RE: response to comment ...".  And it is
writable, not protected, yet it is given a default value selected by the
server when the resource is created, so that a collection doesn't show a
lot of blank friendly names.  

Lisa

Received on Wednesday, 5 March 2003 11:06:24 UTC