W3C home > Mailing lists > Public > uri@w3.org > January 2003

RE: Rationalizing the term URI

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Sun, 26 Jan 2003 15:09:14 +0100
To: "Roy T. Fielding" <fielding@apache.org>
Cc: "Tim Berners-Lee" <timbl@w3.org>, <uri@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEBJGFAA.julian.reschke@greenbytes.de>

> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf Of Roy T.
> Fielding
> Sent: Thursday, January 23, 2003 5:40 PM
> To: Julian Reschke
> Cc: Tim Berners-Lee; uri@w3.org
> Subject: Re: Rationalizing the term URI
>
>
>
> I support Tim's suggestion, even though it will result in many
> descriptive
> changes throughout the specification.
>
> > 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.
>
> That isn't actually a problem.  There is no current BNF rule for URI,
> and thus any spec that used it would necessarily be doing so in an
> informal way.  My observation has been that most specifications, when
> referring to URI in an informal way, do expect the possibility that
> it may include a fragment.

OK, I think this is an important statement. Any spec that currently refers
to RFC2396 for URIs should either

- use BNF terms such as "absoluteURI" instead (if that's what's meant) or
- clearly define what RFC2396 construct it's talking about.

> > 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?
>
> The existing BNF rules already do that.  They would not be changed.

I'm still not happy that absoluteURIs don't have fragment identifiers, while
URIs may. That's not really intuitive.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 26 January 2003 09:10:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:31 GMT