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

Hugh Cayless <[email protected]> Wed, 3 May 2017 20:03:35 -0400
Newsgroups gmane.text.tei.general
Message-ID <[email protected]>
--Apple-Mail-BA367575-280F-4E69-A67F-7EB7B118375F
Content-Type: text/plain;
	charset=cp932
Content-Transfer-Encoding: quoted-printable

Those are the cards we've been dealt, yeah.=20

Sent from my phone.=20

> On May 3, 2017, at 19:53, John P. McCaskey <[email protected]> wrot=
e:
>=20
> So, bottom line: A standalone fragment identifier refers to the loaded doc=
ument and all the xml:base values above it in the hierarchy are irrelevant. E=
ncoders cannot use xml:base to direct a standalone #fragment value to a loca=
tion outside the loaded document.
>=20
> Is that right?
>=20
> --
>=20
>=20
>> On 5/3/2017 6:20 PM, Hugh Cayless wrote:
>> No. This clarifies the expected behavior when (e.g.) you have @xml:base=3D=
"#frag". It says nothing whatever about <p rendition=3D"#foo">. I don't thin=
k these specifications interact in the way you're positing. Quite the opposi=
te.
>>=20
>>> On Wed, May 3, 2017 at 6:13 PM, John P. McCaskey <[email protected]=
om> wrote:
>>> The special behavior of same-document references in RFC 3986 is disavowe=
d by W3C:=20
>>> 4.4 Interpretation of same-document references
>>>=20
>>> RFC 3986 defines certain relative URI references, in particular the empt=
y string and those of the form #fragment, as same-document references. Deref=
erencing of same-document references is handled specially. However, their us=
e as the value of an xml:base attribute does not involve dereferencing, and X=
ML Base processors should resolve them in the usual way. In particular, xml:=
base=3D"" does not reset the base URI to that of the containing document.
>>>=20
>>> Note:
>>>=20
>>> Some existing processors do treat these xml:base values as resetting the=
 base URI to that of the containing document, so the use of such values is s=
trongly discouraged.
>>> This says:
>>> RFC 3986 defines special =81gdereferencing=81h of empty strings and #fra=
gments. But over here in XML-land, we don=81ft do =81gdereferencing.=81g Tha=
t=81fs not a word we use here. Ignore that stuff about same-document referen=
ces. Just resolve empty strings and #fragments as specified in the W3C Recom=
mendation above. And those of you who did carry that stuff over from 3986 to=
 XML-land, shame on you. You messed things up for the rest of us.=20
>>>=20
>>> A note has:
>>> 5. The meanings of xml:base=3D"" and xml:base=3D"#frag" have been clarif=
ied;
>>> This says:=20
>>> In this second version of this recommendation, we added paragraph 4.4 sp=
ecifically to get you 3986 people to stop polluting our W3C with your specia=
l cases. Stop doing that.
>>> No?
>>>=20
>>> -- John
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On 5/3/2017 5:09 PM, Hugh Cayless wrote:
>>>> That's exactly what it does. It's just that the behavior of same-docume=
nt references is prescribed in such a way that they end up resolving to the c=
urrent document regardless of the value of the @xml:base.
>>>>=20
>>>> Put another way, @xml:base has an influence on what the client applicat=
ion will retrieve when it dereferences a URI and retrieves the referenced do=
cument, but in the case of same-document references no such retrieval is exp=
ected to occur=81\it's assumed the client already has the document.
>>>>=20
>>>>> On Wed, May 3, 2017 at 4:29 PM, John P. McCaskey <mailbox@johnmccaskey=
.com> wrote:
>>>>> Oh. I thought it obvious they all resolved the same.=20
>>>>>=20
>>>>> I think the same about this one. You think otherwise?
>>>>>=20
>>>>> <div xml:base=3D"http://www.myteiproject.com/"
>>>>>   <div xml:base=3D"images/">
>>>>>     <div>
>>>>>       <graphic url=3D"logo.jpg">
>>>>>     </div>
>>>>>     <div xml:base=3D"http://www.dictionary.com/words/">
>>>>>       <p xml:base=3D"a.html">
>>>>>         <ref target=3D"#apple">apple</ref>
>>>>>       </p>
>>>>>     </div>
>>>>>   </div>
>>>>> </div>=20
>>>>> I didn=81ft think xml:base had any necessary relation to the current d=
ocument. I thought in XML (not HTML), it just sets a path for URIs below it.=

>>>>>=20
>>>>> --
>>>>>=20
>>>>>> On 5/3/2017 3:42 PM, Hugh Cayless wrote:
>>>>>> Well, we don't know about the third one, except that it points to wha=
tever element *in the same document* has the @xml:id "apple". When an applic=
ation attempts to dereference it, it should make the URI in @ref absolute an=
d check it against the base (http://www.dictionary.com/words/a.html), discov=
er they are identical, decide it doesn't need to fetch anything, and go look=
ing in the current document for the element with the id "apple".
>>>>>>> On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey <mailbox@johnmccask=
ey.com> wrote:
>>>>>>> Are people proposing that these targets do not all resolve=20
>>>>>>> to the same http://www.dictionary.com/words/a.html#apple?
>>>>>>>=20
>>>>>>> <div xml:base=3D"http://www.dictionary.com/">
>>>>>>>     <p xml:base=3D"words/">
>>>>>>>         <ref target=3D"a.html#apple">apple</ref>
>>>>>>>     </p>
>>>>>>> </div>
>>>>>>>=20
>>>>>>> <div xml:base=3D"http://www.dictionary.com/words/">
>>>>>>>     <p xml:base=3D"a.html">
>>>>>>>         <ref target=3D"#apple">apple</ref>
>>>>>>>     </p>
>>>>>>> </div>
>>>>>>>=20
>>>>>>> <div xml:base=3D"http://www.dictionary.com/words/a.html">
>>>>>>>     <p>
>>>>>>>         <ref target=3D"#apple">apple</ref>
>>>>>>>     </p>
>>>>>>> </div>
>>>>>>>=20
>>>>>>> <div xml:base=3D"http://www.dictionary.com/">
>>>>>>>     <p>
>>>>>>>         <ref target=3D"words/a.html#apple">apple</ref>
>>>>>>>     </p>
>>>>>>> </div>
>>>>>>>=20
>>>>>>> --=20

--Apple-Mail-BA367575-280F-4E69-A67F-7EB7B118375F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Those are the cards we've been dealt, y=
eah.&nbsp;<br><br>Sent from my phone.&nbsp;</div><div><br>On May 3, 2017, at=
 19:53, John P. McCaskey &lt;<a href=3D"mailto:[email protected]">mai=
[email protected]</a>&gt; wrote:<br><br></div><blockquote type=3D"cite">=
<div>
 =20
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"=
>
 =20
 =20
    <p><font size=3D"-1">So, bottom line: A standalone fragment identifier
        refers to the loaded document and all the <a class=3D"moz-txt-link-f=
reetext" href=3D"xml:base">xml:base</a> values above
        it in the hierarchy are irrelevant. Encoders cannot use <a class=3D"=
moz-txt-link-freetext" href=3D"xml:base">xml:base</a>
        to direct a standalone #fragment value to a location outside the
        loaded document.</font></p>
    <p><font size=3D"-1">Is that right?</font></p>
    <p><font size=3D"-1">--<br>
      </font></p>
    <p><font size=3D"-1"></font><br>
    </p>
    <div class=3D"moz-cite-prefix"><font size=3D"-1">On 5/3/2017 6:20 PM,
        Hugh Cayless wrote:</font><br>
    </div>
    <blockquote cite=3D"mid:CAObhq+ce0XdEgfuUGGf=3DvMHj4JtPtAGwoe9BgL_Hxqc_H=
[email protected]" type=3D"cite">
      <div dir=3D"ltr"><font size=3D"-1">No. This clarifies the expected
          behavior when (e.g.) you have @<a class=3D"moz-txt-link-freetext" h=
ref=3D"xml:base=3D">xml:base=3D</a>"#frag". It says
          nothing whatever about &lt;p rendition=3D"#foo"&gt;. I don't
          think these specifications interact in the way you're
          positing. Quite the opposite.</font></div>
      <div class=3D"gmail_extra"><font size=3D"-1"><br>
        </font>
        <div class=3D"gmail_quote"><font size=3D"-1">On Wed, May 3, 2017 at
            6:13 PM, John P. McCaskey <span dir=3D"ltr">&lt;<a moz-do-not-se=
nd=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">mailb=
[email protected]</a>&gt;</span>
            wrote:</font><br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor=3D"#FFFFFF" text=3D"#000000">
              <p>The special behavior of same-document references in RFC
                3986 is disavowed by W3C: <br>
              </p>
              <span class=3D"">
                <blockquote>
                  <p><font size=3D"-2">4.4 Interpretation of same-document
                      references<br>
                      <br>
                      RFC 3986 defines certain relative URI references,
                      in particular the empty string and those of the
                      form #fragment, as same-document references.
                      Dereferencing of same-document references is
                      handled specially. However, their use as the value
                      of an <b><a moz-do-not-send=3D"true" class=3D"m_-36802=
29684002831364moz-txt-link-freetext">xml:base</a>
                        attribute does not</b> <b>involve </b>dereferencing,=

                      and XML Base processors should resolve them in the
                      usual way. In particular, <a moz-do-not-send=3D"true" c=
lass=3D"m_-3680229684002831364moz-txt-link-freetext">xml:base=3D</a>""
                      does not reset the base URI to that of the
                      containing document.<br>
                      <br>
                      Note:<br>
                      <br>
                      Some existing processors do treat these <a moz-do-not-=
send=3D"true" class=3D"m_-3680229684002831364moz-txt-link-freetext">xml:base=
</a>
                      values as resetting the base URI to that of the
                      containing document, so the use of such values is
                      strongly discouraged.</font><br>
                  </p>
                </blockquote>
              </span> This says:<br>
              <blockquote>RFC 3986 defines special =E2=80=9Cdereferencing=E2=
=80=9D of
                empty strings and #fragments. But over here in XML-land,
                we don=E2=80=99t do =E2=80=9Cdereferencing.=E2=80=9C That=E2=
=80=99s not a word we use
                here. Ignore that stuff about same-document references.
                Just resolve empty strings and #fragments as specified
                in the W3C Recommendation above. And those of you who
                did carry that stuff over from 3986 to XML-land, shame
                on you. You messed things up for the rest of us. <br>
              </blockquote>
              <br>
              A note has:<br>
              <blockquote><font size=3D"-2">5. The meanings of <a moz-do-not=
-send=3D"true" class=3D"m_-3680229684002831364moz-txt-link-freetext">xml:bas=
e=3D</a>""
                  and <a moz-do-not-send=3D"true" class=3D"m_-36802296840028=
31364moz-txt-link-freetext">xml:base=3D</a>"#frag"
                  have been clarified;</font><br>
              </blockquote>
              This says: <br>
              <blockquote>In this second version of this recommendation,
                we added paragraph 4.4 specifically to get you 3986
                people to stop polluting our W3C with your special
                cases. Stop doing that.<br>
              </blockquote>
              No?<span class=3D"HOEnZb"><font color=3D"#888888"><br>
                  <br>
                  -- John</font></span>
              <div>
                <div class=3D"h5"><br>
                  <br>
                  <br>
                  <br>
                  <br>
                  <br>
                  <div class=3D"m_-3680229684002831364moz-cite-prefix">On
                    5/3/2017 5:09 PM, Hugh Cayless wrote:<br>
                  </div>
                  <blockquote type=3D"cite">
                    <div dir=3D"ltr">That's exactly what it does. It's
                      just that the behavior of same-document references
                      is prescribed in such a way that they end up
                      resolving to the current document regardless of
                      the value of the @<a moz-do-not-send=3D"true" class=3D=
"m_-3680229684002831364moz-txt-link-freetext">xml:base</a>.
                      <div><br>
                      </div>
                      <div>Put another way, @<a moz-do-not-send=3D"true" cla=
ss=3D"m_-3680229684002831364moz-txt-link-freetext">xml:base</a>
                        has an influence on what the client application
                        will retrieve when it dereferences a URI and
                        retrieves the referenced document, but in the
                        case of same-document references no such
                        retrieval is expected to occur=E2=80=94it's assumed t=
he
                        client already has the document.</div>
                    </div>
                    <div class=3D"gmail_extra"><br>
                      <div class=3D"gmail_quote">On Wed, May 3, 2017 at
                        4:29 PM, John P. McCaskey <span dir=3D"ltr">&lt;<a m=
oz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a>&gt;</span>
                        wrote:<br>
                        <blockquote class=3D"gmail_quote" style=3D"margin:0
                          0 0 .8ex;border-left:1px #ccc
                          solid;padding-left:1ex">
                          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                            <p><font size=3D"-1">Oh. I thought it obvious
                                they all resolved the same. <br>
                              </font></p>
                            <p><font size=3D"-1">I think the same about
                                this one. You think otherwise?<br>
                              </font></p>
                            <pre><font size=3D"-1">&lt;div <a moz-do-not-sen=
d=3D"true" class=3D"m_-3680229684002831364m_-7516606003097729134moz-txt-link=
-freetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_-3680229684=
002831364m_-7516606003097729134moz-txt-link-rfc2396E" href=3D"http://www.myt=
eiproject.com/" target=3D"_blank">"http://www.myteiproj<wbr>ect.com/"</a>
  &lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7516=
606003097729134moz-txt-link-freetext">xml:base=3D</a>"images/"&gt;
    &lt;div&gt;
      &lt;graphic url=3D"logo.jpg"&gt;
    &lt;/div&gt;
    &lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75=
16606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a=
><span class=3D"m_-3680229684002831364m_-7516606003097729134m_-1417418399130=
310658moz-txt-link-rfc2396E">"<a moz-do-not-send=3D"true" class=3D"m_-368022=
9684002831364m_-7516606003097729134moz-txt-link-freetext" href=3D"http://www=
" target=3D"_blank">http://www</a>.<a moz-do-not-send=3D"true" href=3D"http:=
//dictionary.com/words/" target=3D"_blank">dictionar<wbr>y.com/words/</a>"</=
span>&gt;
      &lt;p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75=
16606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a=
>"a.html"&gt;
        &lt;ref target=3D"#apple"&gt;apple&lt;/ref&gt;
      &lt;/p&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;=20
</font></pre><p><font size=3D"-1">I didn=E2=80=99t think <a moz-do-not-send=3D=
"true" class=3D"m_-3680229684002831364m_-7516606003097729134moz-txt-link-fre=
etext">xml:base</a> had any necessary relation to the current document. I th=
ought in XML (not HTML), it just sets a path for URIs below it.</font></p><p=
><font size=3D"-1">--
</font></p><div><div class=3D"m_-3680229684002831364h5">
<div class=3D"m_-3680229684002831364m_-7516606003097729134moz-cite-prefix">O=
n 5/3/2017 3:42 PM, Hugh Cayless wrote:
</div><blockquote type=3D"cite"><div dir=3D"ltr">Well, we don't know about t=
he third one, except that it points to whatever element *in the same documen=
t* has the @<a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75=
16606003097729134moz-txt-link-freetext">xml:id</a> "apple". When an applicat=
ion attempts to dereference it, it should make the URI in @ref absolute and c=
heck it against the base (<a moz-do-not-send=3D"true" class=3D"m_-3680229684=
002831364m_-7516606003097729134gmail-m_-1417418399130310658moz-txt-link-rfc2=
396E" href=3D"http://www.dictionary.com/words/a.html" style=3D"white-space:p=
re-wrap" target=3D"_blank">http://www.dictionary.com/wor<wbr>ds/a.html</a>),=
 discover they are identical, decide it doesn't need to fetch anything, and g=
o looking in the current document for the element with the id "apple".</div>=
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey <=
span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true" href=3D"mailto:mailbox@john=
mccaskey.com" target=3D"_blank">[email protected]</a>&gt;</span> wrot=
e:
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <pre><font size=3D"-1">Are people proposing that these targets do not al=
l resolve=20
to the same <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75=
16606003097729134m_-1417418399130310658moz-txt-link-freetext" href=3D"http:/=
/www.dictionary.com/words/a.html#apple" target=3D"_blank">http://www.diction=
ary.com/word<wbr>s/a.html#apple</a>?

</font><font size=3D"-1">&lt;div <a moz-do-not-send=3D"true" class=3D"m_-368=
0229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-fre=
etext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_-36802296840028=
31364m_-7516606003097729134m_-1417418399130310658moz-txt-link-rfc2396E" href=
=3D"http://www.dictionary.com/" target=3D"_blank">"http://www.dictionar<wbr>=
y.com/"</a>&gt;
    &lt;p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7516=
606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a>"=
words/"&gt;
        &lt;ref target=3D"a.html#apple"&gt;apple&lt;/r<wbr>ef&gt;
    &lt;/p&gt;
&lt;/div&gt;

&lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660=
6003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a m=
oz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660600309772913=
4m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.=
com/words/" target=3D"_blank">"http://www.dictionar<wbr>y.com/words/"</a>&gt=
;
    &lt;p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7516=
606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a>"=
a.html"&gt;
        &lt;ref target=3D"#apple"&gt;apple&lt;/ref&gt;
    &lt;/p&gt;
&lt;/div&gt;

&lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660=
6003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a m=
oz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660600309772913=
4m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.=
com/words/a.html" target=3D"_blank">"http://www.dictionar<wbr>y.com/words/a.=
html"</a>&gt;
    &lt;p&gt;
        &lt;ref target=3D"#apple"&gt;apple&lt;/ref&gt;
    &lt;/p&gt;
&lt;/div&gt;

&lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660=
6003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D</a><a m=
oz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-751660600309772913=
4m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.=
com/" target=3D"_blank">"http://www.dictionar<wbr>y.com/"</a>&gt;
    &lt;p&gt;
        &lt;ref target=3D"words/a.html#apple"&gt;ap<wbr>ple&lt;/ref&gt;
    &lt;/p&gt;
&lt;/div&gt;</font><span class=3D"m_-3680229684002831364m_-75166060030977291=
34HOEnZb"><font color=3D"#888888">
<font size=3D"-1">
--=20
</font></font></span></pre>
  </div>

</blockquote></div>
</div>



</blockquote>
</div></div></div></blockquote></div>
</div>



</blockquote>
</div></div></div></blockquote></div>
</div>



</blockquote>
</div></blockquote></body></html>=

--Apple-Mail-BA367575-280F-4E69-A67F-7EB7B118375F--