W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: displayname and uniqueness

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 2 Aug 2004 23:51:08 -0400
To: WebDAV <w3c-dist-auth@w3.org>
Message-ID: <OF8CB3044F.31BF69AB-ON85256EE5.0014A1A2-85256EE5.0015298E@us.ibm.com>
Brian wrote on 08/02/2004 02:29:32 PM:

> On Jul 30, 2004, at 4:27 AM, Geoffrey M Clemm wrote:
> > Brian wrote on 07/29/2004 08:11:22 PM:
> >
> >  > 2518 doesn't address whether the displaynames on
> >  > resources within a given collection must be unique.
> >  > I presume there is no uniqueness constraint,
> >
> > That is correct.
> >
> > > but besides stating that,
> >
> > Since we cannot enumerate all constraints that do not hold,
> > we would only do so if this has turned out to be a source
> > of non-interoperability.  Is this the case?
> I'm not sure I understand what you mean.  What other
> of constraints do you think would need to be
> enumerated?

My point was just that this is one of many possible constraints
that do not hold, and therefore we would need some motivation
to say something about this constraint (such as that it was
a source on non-interoperability).

> > > should the spec give some
> >  > guidance to clients on what to do when there are
> >  > duplicates?  What would that guidance be?
> >
> > I'm not sure what kind of guidance you have in mind here.
> > Could you provide an example?
> I was hoping you'd be able to answer that.  I suppose
> it could be, for instance, something as simple as
> "use the final element of the URL for disambiguation".

I don't see that the specification can make that kind of
a recommendation.  It is true that every member of a single
collection has a distinct final URI segment, but whether that
is a useful way of disambiguating two resources for a given
user is application/resource dependent.

So I guess my response would be "no, the spec shouldn't give
guidance to the clients on what to do when two members of a
collection have the same displayname".

Received on Monday, 2 August 2004 23:52:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT