Re: #foo URI references

>>> Fair enough.  So the special interpretation of "#foo" in the resource
>>> denoted by "" is extended to  
>>> "blargh#foo"
>>> and "" as well.
>>> But it seems to me that (for good or ill) this also means that if a
>>> base URI is available, say "", then
>>> "#foo" now means "".
>>> Is this a correct reading of 2396 bis?


>> And if John is reading it correctly (he is reading it as I did),
>> then this is the crux of my problem with it.
> I've reread
> rfc2396bis.html?rev=1.64#same-document
> but it seems that my studying the text (and JohnC's studying of it)
> isn't necessarily sufficient to answer my question which is as follows.
> In RFC 2396, it makes clear that:
>       If the path component is empty and the scheme, authority, and
>       query components are undefined, then it is a reference to the
>       current document and we are done.
> Given either the following document at
> <doc xml:base="">
>   <para href="#foo">xxx</para>
>   <para id="foo">yyy</para>
> </doc>
> or the following document at
> <html>
> <head>
> <title>t</title>
> <base href="">
> </head>
> <body>
> <p><a href="#foo">xxx</a></p>
> <p><a name="foo">yyy</a></p>
> </body>
> </html>
> the href in either case points to the element in the same document
> containing yyy.

href is an attribute that contains a URI reference that might be
interpreted by the reference interpreter as a pointer to a name
defined by an attribute on an element within the document being
interpreted.  Regardless, the contents are a URI reference and the
target is identified by the URI within the context in which it is

> Some readings of 2396bis interpret it to be saying that the href above
> points to (or, in the html  
> case,
> which does not necessarily
> exist and is certainly not my intended target.

It does exist -- it is defined by the document itself.  Both readings
say the same thing -- they just use different perspectives to say it.
The original was from the view of the document processor, whereas the
draft wording is from the view of the URI processor (with further
instruction to a document processor that is processing a retrieval
action).  In both cases, the target of the reference is the same and
the result is the same.

> Is this significant change in meaning (and behavior for a variety of
> deployed tools) the intended interpretation of 2396bis?

There is no change in meaning (I wrote both sentences in both documents
and I am absolutely certain of that).  Base has always defined a name
space for the document's reference resolver, and the behavior will
be the same as it should have been before.  Any other interpretation
would eliminate the ability to set bookmarks and location bars to the
identified URI.  The observable differences between the two are the
internal interface between the document processor and its relative URI
resolver, which has been simplified by the new wording such that it
better reflects what most browsers do today, and in the behavior of
the document processor when the referenced URI matches the base URI
in every way except the fragment (a situation which was left undefined
before, but that browsers implemented to be a same-document reference
for the sake of performance and because it simplified their own
interface with the reference resolver).

That is, the correct behavior is to parse the reference into a URI
before deciding whether or not it is a same-document reference.
The effect of this change, when implemented, has no impact on the
protocol *except* when a person is deliberately abusing the base URI
by assigning it an unrelated URI for the purpose of creating an
artificial shorthand notation for external references.  It should be
no surprise that such usage will not be supported by the standard,
since it never worked with the majority of deployed implementations.

In any case, the change is needed for consistent interpretation of
URI references in non-document-retrieval conditions (e.g., SemWeb).


Received on Thursday, 29 January 2004 20:52:02 UTC