W3C home > Mailing lists > Public > www-tag@w3.org > September 2002

Re: "absolute URI reference" considered awkward (and in one case, overly constraining)

From: Tim Berners-Lee <timbl@w3.org>
Date: Fri, 6 Sep 2002 14:00:51 -0400
Message-ID: <006e01c255cf$56b5ee30$84001d12@w3.org>
To: "Tim Bray" <tbray@textuality.com>, "Dan Connolly" <connolly@w3.org>
Cc: <www-tag@w3.org>

I happily left for vacation thinking that the TAG had at least started to
clear up one big mess, and find that the change had been reversed
when I got back!  Ah well! As I think this is important, I will add my
weight to the
argument for the new, cleaner definition of URI.

I would point out on top of the existing arguments which have
been made that "Absolute URI Reference" is a broken term.

It is important to distinguish between the string which identifies
something and the BNF for a string in a document which
is used to specify the first string.  The first is an identifier.
The second has been called a "reference".   A reference
can use a relative form.

For the identifier  http://example.org/bar#foo we can only as is
use the term "Absolute URI reference", which is terrible because
we are talking about the actual identifier and NOT just a form
of reference.

What you actually want to quote in most specs' BNF is a
reference. This can be relative or absolute. The terms "relative
URI" and "absolute URI" are nonsense: these are just
references.  "relative URI reference" makes sense ...
but  I can't think of a time when one would want something
which could be relative and could *not* be absolute.

"Absolute URI reference" means more or
less "A string for referring to a URI in a document but
constrained so that it is equal to the string which is the document's
actual identifier".  We only go through the loop because the #fragid
was left off the definition of URI, but by doing this fudge
we magically get it back.   Aaauuugh!

So the old system is a big mess and I agree that while  RFC2386 does
say that, that we do better to clear it up now.  Note, to ease the pain:

- "URI reference",  which is what most specs should be calling out,
  does not change.

So the term I would like the document to use are as follows:

What: The actual identifier in general, with or without #fragid
Examples:  http://www.w3.org/    mailto:spam@ftc.gov
Old:  Absolute URI Reference
New:  URI

What: A reference to the above
Examples:  http://www.w3.org/    /   mailto:spam@ftc.gov  /foo#bar   #bar
Old:  URI Reference
New:  URI Reference

What: An identifier with no "#"
Old:  URI
New:   <need to make something up maybe>

With regards to the last line, I'd point out that in  most cases where you
want to restrict something to having no "#"  you very likely want to
restrict it to being a particular scheme.
For example, you must need it to refer to a document or a mailbox
or something, so probably you want a term like "mailbox identifier
(mailto:...)" or
"http document identifier (http:...)".   A first test will be whether we
need it in the architecture document.

Tim BL


----- Original Message -----
From: "Tim Bray" <tbray@textuality.com>
To: "Dan Connolly" <connolly@w3.org>
Cc: <www-tag@w3.org>
Sent: Friday, September 06, 2002 12:54 PM
Subject: Re: "absolute URI reference" considered awkward (and in one case,
overly constraining)

> Dan Connolly wrote:
> > But there's some subtlety... the "endpoints" of the link
> > are absolute URI references, even though the syntax
> > of the reference is relative. I suppose we just explained
> > that a few paragraphs above in the bit about relative
> > URI references.
> Right some language in the doc would be appropriate to make it clear
> that we understand the difference between the syntactic expression
> embedded in some resource and the version that actually gets used to
> access resources.
> > Stuart and company, are you *sure* you don't want to use
> > the term URI to include things like http://example/x#y?
> I think a few of us would like this, but we would be pretty severely
> inconsistent with RFC2396. -Tim
> >
> >
Received on Friday, 6 September 2002 14:00:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:54 UTC