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

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

Hi Michael,

> On May 9, 2017, at 6:52 PM, Michael Kay <mike@saxonica.com> wrote:
> 
> 
>> On 9 May 2017, at 16:46, Andrew S. Townley <ast@atownley.org> wrote:
>> 
>> 
>> The specific portions of RFC 3986 that are most relevant to this discussion are Sections 4.4, Same-Document Reference, and Section 5.1 Establishing a Base URI.
>> 
>> The rest of Section 5 defines operations and examples on how to actually create a complete URI based on having a base URI and some URI fragment, so they’re independent of exactly HOW the base URI was identified in the first place.
>> 
>> The crux of this whole question/discussion seems to be Section 5.1 that describes 4 ways to establish a base URI. 
> 
> I don't think there's much dispute about how to establish a base URI and how to use it to resolve a relative reference. The crux to me is section 4.4 on same-document reference, which talks about using (dereferencing) the (resolved, absolute) URI to obtain a resource, and here it gives the surprising rule that if:
> 
> * the base URI is http://A/
> 
> and
> 
> * the URI you are dereferencing is http://A/
> 
> then
> 
> * 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/. 

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?

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

If you “dereference for a retrieval action [type of reference]” ("making use of a URI in order to retrieve a representation [sequence of octets and metadata] of its associated resource”) B, then the target (octets and metadata) is defined to be within the same entity as the reference.

I think we’re together to this point.  What I don’t quite follow is the “unrelated to what you might find” part.

If you have a same document reference, then it doesn’t matter what you might find because what you’re addressing is either a) the complete set of octets and metadata retrieved by using the resource identifier or b) a subset of that resource identified by the fragment in a resource-specific way.

If you keep your scope of base URI’s right relative to the use of the resolved absolute URIs, I don’t see how you can go wrong here.  Maybe what’s not clear is that this needs to be ensured so you don’t assume the content of a content-specified base URI is within the same entity as any other base URI defined by the content.

Is that what you mean?

> 
> But this rule only applies if "the URI reference is dereferenced for a retrieval action". I think this phrase has to be read in the light of 1.2.2, which says:
> 
> Given a URI, a system may attempt to perform a variety of operations
>   on the resource, as might be characterized by words such as "access",
>   "update", "replace", or "find attributes".  Such operations are
>   defined by the protocols that make use of URIs, not by this
>   specification.
> 
> and this means that if a higher-level protocol chooses to define an operation (say "access" or "fetch") as behaving differently from a "retrieval action" in the sense defined by the RFC, then it is at liberty to do so.

I think I see your issue here, but isn’t the spec just making that qualification for retrieval dereferences not resulting in a new retrieval action (e.g. idempotent GET)?

Without the qualification, which, to me only discusses the side effects of same-document dereferences for retrieval actions, it would simply omit the guidance that you could possibly assume idempotent GET and you’d need to perform whatever action when dereferencing the URI.

To me the subject of that whole sentence/paragraph is the side effects of retrieval actions, but it doesn’t go so far as to say anything about any other resource operations being able do behave differently other than not being bound by the “should not” constraint on the retrieval action itself.

Or did I read it wrong?

I haven’t gone through this spec at this level of detail before today for quite a long time, so maybe I’m reading more into it than I should.  I’ve never actually worried too much about this part because it seems like it’s just a lead-in to the potential caching usage/application in the following paragraph.

Assumptions, assumptions, and we all know how that goes…

Cheers,

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