- 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>
> 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 terminology > on the URI spec which has confused people. It is my considered opinion that > 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 of > 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. Well. 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 something? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 23 January 2003 09:55:06 UTC