W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

RE: Rationalizing the term URI

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Thu, 23 Jan 2003 15:53:36 +0100
To: "Tim Berners-Lee" <timbl@w3.org>, <uri@w3.org>
Cc: <www-tag@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCGEJKGEAA.julian.reschke@greenbytes.de>

> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Tim
> Berners-Lee
> Sent: Thursday, January 23, 2003 2:25 PM
> To: uri@w3.org
> Cc: www-tag@w3.org
> Subject: Rationalizing the term URI
> I would very much like us to take the opportunity to clean up the
> on the URI spec which has confused people.  It is my considered opinion
> this would be far preferable:
> URI  - the actual identifier string, with or without a #fragid.
> URI reference - a string used in a language to specify a URI, for which
> relative form may be used where a base exists. ((This is not the  only way
> specifying the value of a URI - one can use various
> character sets, namespace prefixes, etc))
> The spec would do well to define the function from  base and reference to
> URI and back again
>     rel(u, base)      and abs(u, bae)
> and to point out that you can use abs(rel(u, base), base) for u in all
> circumstances.


1) I think it's an extremely bad idea to simply change the definition of the
term, because it will negatively affect tons of other RFCs/recommendations.
If you need a simple term to talk about URIs + optional fragment, define a
new one.

2) On the other hand, *if* the definition is changed, there's no way to
avoid defining a *new* term for what a URI used to be. Or am I missing


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 23 January 2003 09:55:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC