Re: @xml:base with @rendition (and maybe other pointers)

In XML, isn’t “base URI“ something specific to an element, not to the 
document?

If so, the passage quoted is not saying that fragment IDs can point only 
to the document they are in, just that a fragment ID points to the same 
document as the base URI in effect for the containing XML element.

Doesn’t this paragraph <https://www.w3.org/TR/xmlbase/#matching> say 
fragment IDs should honor the complete xml:base value in effect for the 
attribute’s element?

John


On 5/2/2017 4:07 PM, Hugh Cayless wrote:
> I think it's a perfectly safe, rational, and intuitive one. And, 
> moreover, one that follows https://tools.ietf.org/html/rfc3986#page-27 
> section 4.4:
>
>     When a URI reference refers to a URI that is, aside from its fragment
>     component (if any), identical to the base URI (Section 5.1 <https://tools.ietf.org/html/rfc3986#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.
>
> On Tue, May 2, 2017 at 3:55 PM, John P. McCaskey 
> <[email protected] <mailto:[email protected]>> wrote:
>
>     On 5/2/2017 3:30 PM, Hugh Cayless wrote:
>
>         I vote fragment ids ignore @xml:base!
>
>     I think that’s a risky and and unnatural limitation.
>     @xml:base="http://www.dictionary.html/"
>     <http://www.dictionary.html/> followed by @xml:base="a.html"
>     followed by @target="#apple" seems a good way to point to
>     "http://www.dictionary.com/a.html#apple"
>     <http://www.dictionary.com/a.html#apple>.
>
>     I’d prefer saying some named attributes (e.g., @rendition) ignore
>     xml:base—which puts us back to
>     Piotr’s tei.localref.
>
>     But then there is some value is centralizing a project’s rendition
>     mappings in one external file.
>
>     Hmm . . .
>
>
>
>
>>     Yes, hence my view of @xml:base as unintentionally evil. My
>>     reading of the section of RFC 3986 you quote is that the
>>     dereferencing of a fragment id should not result in fetching a
>>     new document (as it might if @xml:base was different from the
>>     current document). Moreover, in the same document, "#" is
>>     defined, along with "", as a same-document reference, again
>>     regardless of the value of @xml:base, so I think the implication
>>     is that fragment identifiers always refer to the current document.
>>
>>     All that said, there seems to be a fair amount of confusion out
>>     there from my quick Googling around, leading to inconsistent
>>     implementations. Also, the resolution of fragment IDs is
>>     dependent on the media type, so I suppose in theory we get to
>>     pick what it does :-). I vote fragment ids ignore @xml:base!
>>
>>     If this is true, we really ought to say something about it in the
>>     Guidelines so that implementors don't go off the rails.
>>
>>     On Tue, May 2, 2017 at 2:52 PM, Syd Bauman
>>     <[email protected] <mailto:[email protected]>> wrote:
>>
>>         Martin has taken the words right out of my mouth:
>>         > One unanswered question might be whether the dereferencing process
>>         > in a prefixDef is supposed to take account of @xml:base,
>>         though...
>>
>>         But I also have to admit, I'm not 100% sure how
>>         | <note xml:base="http://www.example.edu/SydNotes.xml
>>         <http://www.example.edu/SydNotes.xml>" target="#silly"/>
>>         is supposed to be dereferenced. I have always thought it meant
>>         the element at http://www.example.edu/SydNotes.xml#silly
>>         <http://www.example.edu/SydNotes.xml#silly>. But RFC
>>         3986 "Uniform Resource Identifier (URI): Generic Syntax" says
>>         |  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.
>>         which confuses me.
>>
>>
>>         All this leads me to prefer <prefixDef> over @xml:base.
>>
>>
>
>