Re: #foo URI references

At 07:53 PM 2003-09-19, Roy T. Fielding wrote:
>There is no change in reference semantics between this and 2396.

Are you sure?

[I speak as a fool.]

Under the old regime, if a hyper-document contains a reference by means
of a fully-qualified URI-reference, that is to say an absolute URI and
a #fragment clause, the referential semantics would appear to have been
changed by the current language.

In RFC 2396, if the reference contains an absolute URI then the reference is
never compared with the BASE and the reference is interpreted as to the
resource identified in the URI without regard for the fact that the current
DOM is a representation of that resource.  Caching and retrieval behavior
is undefined.  Whether the User Agent navigates to another node in the 
currently
constructed DOM or retrieves the resource afresh from wherever across the net,
either is regarded as conforming to the referential semantics of the reference.

In the present draft this behavior is tightened so that all references are
compared to the incumbent BASE for the current DOM and no refresh is performed
if the reference can be satisfied from the current DOM.  This constitutes a
tightening of the referential semantics for the case where the URI-reference
is fully qualified (contains an absolute URI) which happens to agree with the
BASE.

So yes, the behavior is the same as before for #foo references.  But the
specified behavior and therefore the referential semantics has changed for
the case of absoluteURI#foo references.  The referential semantics does not
only include which resource is referred to.  It matters in this case whether
the reference is to any representation of the resource or locally to the
representation making the reference.

Admittedly, the specification has been changed in this case to agree with a
widely-implemented narrowing of the formerly-acceptable behavior, but this
is a change in what the specification asserts by way of referential semantics.

The semantic change is to extend #foo semantics to BASE#foo URI-references.

Al

>Sorry for this retread of an old topic, but I want to be sure that I
>answered your question (and I can't remember if I did).
>
>On Tuesday, July 15, 2003, at 02:11  PM, Paul Grosso wrote:
>>At 12:25 2003 07 11 +0200, Roy T. Fielding wrote:
>>>Paul had asked:
>>>>Are you saying that it never makes sense for an author to use
>>>>xml:base or HTML's BASE element?
>>>
>>>No, it does not change their use.
>>
>>I believe one really needs to be able to author something in a resource
>>that is certain to refer to that same resource.  If you look at most W3C
>>specification's--certainly most of those with which I am familiar in the
>>XML Activity--I think you'll find most links are intra-document links.
>
>To be perfectly clear, the algorithm as stated in draft 03 does not alter
>such use whatsoever.  The result is still the current document, regardless
>of which base is used in the algorithm.  I will try to make that clearer
>in the next revision.
>
>>I continue to believe this serious backward incompatible change to semantics
>>defined by 2396 and assumed by various other specs including XML Base is
>>quite problematic.
>
>I can only conclude that you missed the section.
>
>    4.4  Same-document Reference
>
>    When a URI reference occurring within a document or message
>    refers to a URI that is, aside from its fragment component (if any),
>    identical to the base URI (section 5.1), that reference is called
>    a "same-document" reference. The most frequent examples of
>    same-document references are relative references that are empty
>    or include only the number-sign ("#") separator followed by a
>    fragment identifier.
>
>    When a same-document reference is dereferenced for the purpose
>    of a retrieval action, the target of that reference is defined
>    to be within that current document or message; the dereference
>    should not result in a new retrieval.
>
>In other words, it doesn't matter what the base URI might be at
>that point -- the only relevant question is whether the resulting
>reference (after parsing) differs from the current base URI by
>only the fragment.
>
>There is no change in reference semantics between this and 2396.
>The only thing that changes is the point at which the processor
>determines whether the link is internal or external.  The reason
>for this change is because it corresponds to the separation of
>concerns within most URI-parsing technology, such as browsers,
>which explains why they didn't implement the prior behavior.
>
>The only case that could cause this change to result in an error
>is if the base URI were changed to point to a resource other than
>the one corresponding to this document AND that other resource
>happens to be referenced within this document.  That case is not
>considered relevant because it is a bad idea and wouldn't work
>with existing browsers and caches regardless.  For the tricks you
>described earlier with xml-base, it is trivial to invent a base URI
>that isn't referenced within the document and therefore not subject
>to this discrepancy in behavior.
>
>....Roy

Received on Saturday, 20 September 2003 12:17:17 UTC