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

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]>
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" target="#silly"/>
> is supposed to be dereferenced. I have always thought it meant
> the element at 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.
>