Re: [xml-dev] xml:base and fragments

["C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>]

> On May 9, 2017, at 4:02 PM, Andrew S. Townley <ast@atownley.org> wrote:
> 
> 
>> On May 9, 2017, at 11:16 PM, Michael Kay <mike@saxonica.com> wrote:
> ...
>>> 
>>> According to 4.4, (the part you summarized):
>>> 
>>> When a same-document reference is dereferenced for a retrieval
>>> action, the target of that reference is defined to be within the same
>>> entity (representation, document, or message) as the reference;
>>> therefore, a dereference should not result in a new retrieval action.
>>> 
>>> So when byte stream A (the base URI) is identical to byte stream B (some other URI reference), then we have the “same-document” reference (aside from any fragment component).
>> 
>> No, I think you've gone off at a complete tangent here. 
> 
> Not sure how, but ok.
> 
> I was just saying:
> 
>  if string1 was equal to string2;
>    and string1 was the base URI; 
>    and string2 was the target (your http://A/ example),
>  then you have a ‘same-document’ reference (per spec).
> 
> If you’ve previously retrieved string1 as the base URI, then what the paragraph actually says was that you shouldn’t need to trigger a new retrieval of string2 because both are equal and refer to the same resource content that you have already loaded.
> 
> If you haven’t actually retrieved string1 as the base URI *and* you’re dereferencing the target as part of a retrieval action, then you have no choice but to trigger a new retrieval action (because you don’t have it yet).

You are disagreeing with RFC 3986 (and with some people
who commented on the draft) here.  On your interpretation, a fresh
retrieval will be necessary for any “same-document reference” (as
RFC 3986 defines the term) for which the base URI does not equal
the URI from which the document was retrieved.  

This behavior was predicted and deplored by some comments on
the draft that later became 3986, because it means that any change
to the base URI in a document risks breaking all document-internal
links.  The lead editor explained (several times, I believe) that this
is not in fact what the spec says or recommends. 

RFC 3986 does NOT agree that you have no choice but to trigger
a new retrieval in this situation; it tells you that the target of the link
is *defined* as being within the current document and that a new
retrieval action “should not” be triggered.

On what basis do you believe a piece of software can determine
whether a new retrieval action is needed?  Because the document
was retrieved from URI R and the base URI is a different URI B?

What principle of Web architecture says that two different URIs 
cannot point at the same document?  

> 
> What I still didn’t understand was your:
> 
>>> * the reference is interpreted as a reference to the entity containing the reference, even if that entity is completely unrelated to anything you might find by retrieving the resource at http://A/. 
> 
> Because it must be related if you’ve already loaded it, and it by definition is a "same-document” reference.  How could it be completely unrelated?
> 
> The only way it would be potentially unrelated is if you held a base URI reference that wasn’t the same as the “target reference” because they would, in fact be different resources.  However, then they wouldn’t pass the test for “same document” though.

You should perhaps re-read the definition of “same-document reference” in RFC 3986.
It does not depend on performing two document retrievals and comparing the
results.

> This seems important (because you mentioned it), but I don’t see how it is possible.

There are at least two scenarios where I think most people will find it all makes
perfect sense:  1 the base URI is a canonical URI for the docuent, although in 
fact the document was retrieved from a non-canonical URI.  (E.g the document’s
canonical URI is http://example.com/foo, but the document was retrieved by
requesting the different URI http://www.Example.com/foo.xml.)  2 the base URI
is a URI for a partial document, embedded in the current document either by
entity reference or by XInclude. 


> 
> Either way, I still don’t agree that the paragraph(s) you referenced in Section 4.4 is(are) doing more than providing implementation advice potentially relating to caching in the case of retrieval.  This advice wouldn’t necessarily apply to other protocol operations – especially if they weren’t idempotent – which is why I’m assuming the “should not” is present vs. “must not.”

The statement that 

    When a same-document reference is dereferenced for a retrieval
    action, the target of that reference is defined to be within the same
    entity (representation, document, or message) as the reference;

looks clearly normative to me.  The following statement, that 

    therefore, a dereference should not result in a new retrieval action.

does pretty clearly allow a same-document reference to be 
dereferenced either without or with a new retrieval, but ‘should’ is
a conformance keyword, and describing this sentence as “implementation 
advice” does not seem to me to capture the situation very well.


********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************