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

["Andrew S. Townley" <ast@atownley.org>]

> On May 9, 2017, at 11:16 PM, Michael Kay <mike@saxonica.com> wrote:
> 
>> 
>> Not sure I’m 100% following you here.  Forgive me for typing and thinking, but that way you can spot anything I’m doing wrong as I do it… ;)
>> 
>> A URI is an identifier for a resource.  A reference to the URI is the byte stream content of the URI itself, right?
> 
> I didn't use the term "reference to the URI". I think you probably misunderstood the term "URI Reference". This is the term used in RFC 3986 to mean either a "URI" or a "relative reference". In normal everyday conversation most people call these "absolute URI" and "relative URI" respectively, but those terms are from older specs. RFC 3986 decided that a "relative URI" is not a URI at all, it is (in effect) an abbreviation of a URI.

Actually, I didn’t.  I just turned it around and was restating 4.1 in English and highlighting that a URI Reference non-terminal expansion in either form was a sequence of bytes that are only given meaning by the spec, so in determining “same-document” references, it’s effectively “starts with” string comparison, regardless of which normalization you choose to use.

The question you posed ultimately comes down to the way you interpret the text, so this was me trying to “white board” the build of the meaning from blank page to being able to understand what the spec was trying to say quite literally.

What I get for “typing out loud” I guess. Could also be the dreaded “typing while tired” syndrome… :)

>> 
>> 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).

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.

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

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."

What is your concern behind the observation?  Have you seen this behavior in the wild?

Obviously, your concerns about other and future protocols doing things contravening the RFC in cases other than retrieval would be bad things if they happened, but I don’t see that the RFC gives such a license as you imply.

Cheers,

ast
--
Andrew S. Townley <ast@atownley.org>
http://atownley.org