W3C home > Mailing lists > Public > uri@w3.org > September 2001

Re: Excess URI schemes considered harmful

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 26 Sep 2001 17:29:10 -0400
Message-Id: <Version.32.20010926134510.041c7840@pop.iamdigex.net>
To: Rob Lanphier <robla@real.com>
Cc: <uri@w3.org>
Rob, I don't know if you will find this helpful or still too theoretical.  But
I'll give it a whirl anyway.

I do think your application is being subjected to a lot of discussion that
not pertain.  So here is my feeble attempt to gather some things that IMHO we
could stipulate to a) bound the problem and b) outline the search space
remaining in deciding on a planned solution.

At 12:49 PM 2001-09-26 , Rob Lanphier wrote:
>A "ContentType:" scheme can define equivalencies.  Moreover, it can define
>equivalencies that map directly to equivalencies that already exist in the
>822 header world.
>If the CTURI proposal doesn't define a way of mapping to a canonical form
>for comparison purposes, then I would agree that should be addressed.

A typespace supports tests for equivalence.  So it is possible to reflect this
in the tokens we give the types in a tokespace such as URI land.

These comparisons, however, are private to the typespace.  To compare types
from different typespaces, one first has to register the two typespaces in a
common superspace.

So a normalization or equivalently comparison scheme for the space of
registered MIME types including the registered parameters is readily
as is the preservation into URI syntax of sufficient information to perform
this comparison on the URIs without recovery.

A general normalization or comparison for URIs or types-indicated-via-URIs is
much less readily achievable.

All this says is that in URI land, the MIME types should be their own
name-sub-space with their own subdomain-private normalization and comparison

This can be done either with a dedicated top-level scheme name or with an URN


Received on Wednesday, 26 September 2001 17:24:38 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:39 UTC