Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Tue, 2 May 2017 16:07:43 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <CAObhq+eyE_tVurDaJFQebgK0uR9Db3HFNt-fFrarQszhW-jSYg@mail.gmail.com> |
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]>
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]>
> 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.
>>
>
>
>