W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

RE: Clarification of URI vs. resource

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Fri, 13 Nov 1998 09:29:45 -0800
To: Larry Masinter <masinter@parc.xerox.com>
Cc: w3c-dist-auth@w3.org
Message-ID: <000b01be0f2b$34f5ffe0$d115c380@galileo.ics.uci.edu>
Larry Masinter writes:
> Urk! That wasn't what I was complaining about. The requirement I
> don't understand is the requirement that a resource not appear
> twice in a collection. I don't understand the reason for the requirement.
> If I understood the reason for the requirement, then I might know
> why it should be OK for the same 'resource' to appear in a collection
> twice if that resource is named with different URLs.

The requirement is intended to be: the same *URL* cannot appear more than
once in the same collection.  Multiple instances of the same *resource* are

One rationale for this requirement is to avoid having to have "instance"
identifiers for each URL in a collection, and to avoid handling ordering
issues in the base specification.

The other rationale for this requirement is that having multiple instances
of the same URL in a collection just didn't make sense.  For example,
assuming multiple instances of the same URL are allowed in a collection, if
there is a collection resource R, with URL
http://www.example.com/collection/, and it has members:


That is, when accessed via URL http://www.example.com/collection/ the
absolute form of the URLs of these members is:


What does it mean to have ./hello.html twice?  How can one of these
duplicates be created?  If one instance is deleted, the others must go away
as well (or leave a dangling member of collection).  This issue of having
multiple instances of the same URL in a collection was discussed in the
advanced collections specification as well, and the decision was made there
too not to have multiple instances of the same URL in a collection.

- Jim
Received on Friday, 13 November 1998 12:34:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:18 UTC