- 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>
> 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 UTC