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

Hi Tim, Dan,

So to play things back my summary is that:

1) There is no proposal to change the meaning of the term URI Reference. 

2) You propose that we use the term URI for identifiers that syntactically
match the *absolute* form of URI Reference defined in 2396.

...and the implicit question is perhaps... what's wrong with that?

I think that implicit in the proposal is the resolution of the question of
whether URI References with and without fragment identifiers both identify
resources. Settle that question one way or the other and it becomes
easy(ier) to accept or reject the definition of term URI that includes
fragment IDs. Defining the term URI in the way you propose  seems to settle
this question by stealth.

Is the resource referenced by URI reference

	http://example.org/aDoc#frag1

the same as the resource referenced by the URI reference

	http://example.org/aDoc#frag2

where #frag1 and #frag2 identify different parts of any retrieved
representations?

One view, the "RFC2396 section 4 paragraph 1" view, says... yes these two
references each refer to the same resource - the resource identified by the
URI reference http://example.org/aDoc.

The other view, your view..., says no, each reference refers to a different
resource.

I think that there is appeal in what you propose, but I think it would be
disasterous if there is a divergence in terminology between the W3C/TAG
architecture document and RFC2396 and its successors.

> > > Stuart and company, are you *sure* you don't want to use
> > > the term URI to include things like http://example/x#y?

Personnally... I think that defining URI this way, without concensus with
the community revising RFC2396, will lead to further confusion rather than
clarity.

Regards

Stuart
--

> -----Original Message-----
> From: Tim Berners-Lee [mailto:timbl@w3.org]
> Sent: 06 September 2002 19:01
> To: Tim Bray; Dan Connolly
> Cc: www-tag@w3.org
> Subject: Re: "absolute URI reference" considered awkward (and in one
> case, overly constraining)
> 
> 
> 
> 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
> http://www.w3.org/foo#bar
> 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 Monday, 9 September 2002 12:20:19 UTC