W3C home > Mailing lists > Public > uri@w3.org > February 2002

Re: [Fwd: Re: [xml-dev] creating a URI class]

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 22 Feb 2002 09:43:12 -0500
Message-Id: <200202221442.JAA138726@smtp1.mail.iamworld.net>
To: Dan Connolly <connolly@w3.org>, "Simon St.Laurent" <simonstl@simonstl.com>
Cc: uri@w3.org, elharo@metalab.unc.edu, Mark Nottingham <mnot@mnot.net>
At 06:06 PM 2002-02-19 , Dan Connolly wrote:
>There are cases when the URI spec guarantees that two URIs
>point to the same thing; e.g.
> <http://www.w3.org/>http://www.w3.org/
> <http://www.w3.org/>http://WWW.W3.ORG/
>but that doesn't make the two URIs equal. If you want
>to be sure that consumers realize you mean the same thing,
>I recommend writing it the same way, rather than relying
>on consumers to do scheme-specific equivalence processing.

An individual may reasonably prefer to emphasis the "be strict in what you
emit" side of the equation over the "be broad in what you accept" side.  

But URIs are not only emitted by the "owners" of sub-name-spaces in the overall
URI space.  URIs are to be used in third-party references as well, and here it
is not safe to assume we can attain enough come-lately canonicalization of the
spellings to keep consumers from having to process on the basis of established
equivalence patterns such as case insensitivity.

As a body convened, as the brain trust of a community where URIs are emitted
autonomously by many many actors, we don't have the choice to recommend one or
the other of these sides of the DRUMS principle.  We are simply not doing our
job if we fail to recommend both.

Classes in processing environments can support consumers of URIs just as much
as emitters.  Constructing a class which embeds some well-known
case-insensitivity equivalences is a standards-consistent thing to do and is
not to be dismissed out of hand.  Whether or not to do it depends on the costs
and benefits in the processing environment at hand.  That is not something we
need to, or could readily, agree on.

Received on Friday, 22 February 2002 09:42:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:04 UTC