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

"John P. McCaskey" <[email protected]> Wed, 3 May 2017 19:53:31 -0400
Newsgroups gmane.text.tei.general
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------7772546973DFD9B20F16F996
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

So, bottom line: A standalone fragment identifier refers to the loaded=20
document and all the xml:base values above it in the hierarchy are=20
irrelevant. Encoders cannot use xml:base to direct a standalone=20
#fragment value to a location outside the loaded document.

Is that right?

--


On 5/3/2017 6:20 PM, Hugh Cayless wrote:
> No. This clarifies the expected behavior when (e.g.) you have=20
> @xml:base=3D"#frag". It says nothing whatever about <p=20
> rendition=3D"#foo">. I don't think these specifications interact in the=
=20
> way you're positing. Quite the opposite.
>
> On Wed, May 3, 2017 at 6:13 PM, John P. McCaskey=20
> <[email protected] <mailto:[email protected]>> wrote:
>
>     The special behavior of same-document references in RFC 3986 is
>     disavowed by W3C:
>
>         4.4 Interpretation of same-document references
>
>         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 *xml:base attribute does not* *involve
>         *dereferencing, and XML 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.
>
>         Note:
>
>         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 strongly discouraged.
>
>     This says:
>
>         RFC 3986 defines special =E2=80=9Cdereferencing=E2=80=9D of emp=
ty 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 u=
se 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.
>
>
>     A note has:
>
>         5. The meanings of xml:base=3D"" and xml:base=3D"#frag" have be=
en
>         clarified;
>
>     This says:
>
>         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.
>
>     No?
>
>     -- John
>
>
>
>
>
>
>     On 5/3/2017 5:09 PM, Hugh Cayless wrote:
>>     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 @xml:base.
>>
>>     Put another way, @xml:base 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 the client already has the document.
>>
>>     On Wed, May 3, 2017 at 4:29 PM, John P. McCaskey
>>     <[email protected] <mailto:[email protected]>> wrote=
:
>>
>>         Oh. I thought it obvious they all resolved the same.
>>
>>         I think the same about this one. You think otherwise?
>>
>>         <div xml:base=3D"http://www.myteiproject.com/"
>>         <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/
>>         <http://dictionary.com/words/>"> <p xml:base=3D"a.html"> <ref
>>         target=3D"#apple">apple</ref> </p> </div> </div> </div>
>>
>>         I didn=E2=80=99t think xml:base had any necessary relation to =
the
>>         current document. I thought in XML (not HTML), it just sets a
>>         path for URIs below it.
>>
>>         --=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 whatever element *in the same document* has the
>>>         @xml:id "apple". When an application attempts to dereference
>>>         it, it should make the URI in @ref absolute and check it
>>>         against the base (http://www.dictionary.com/words/a.html
>>>         <http://www.dictionary.com/words/a.html>), discover they are
>>>         identical, decide it doesn't need to fetch anything, and go
>>>         looking in the current document for the element with the id
>>>         "apple".
>>>         On Wed, May 3, 2017 at 3:27 PM, John P. McCaskey
>>>         <[email protected] <mailto:[email protected]>>
>>>         wrote:
>>>
>>>             Are people proposing that these targets do not all
>>>             resolve to the same
>>>             http://www.dictionary.com/words/a.html#apple
>>>             <http://www.dictionary.com/words/a.html#apple>? <div
>>>             xml:base=3D"http://www.dictionary.com/"
>>>             <http://www.dictionary.com/>> <p xml:base=3D"words/"> <re=
f
>>>             target=3D"a.html#apple">apple</ref> </p> </div> <div
>>>             xml:base=3D"http://www.dictionary.com/words/"
>>>             <http://www.dictionary.com/words/>> <p
>>>             xml:base=3D"a.html"> <ref target=3D"#apple">apple</ref> <=
/p>
>>>             </div> <div
>>>             xml:base=3D"http://www.dictionary.com/words/a.html"
>>>             <http://www.dictionary.com/words/a.html>> <p> <ref
>>>             target=3D"#apple">apple</ref> </p> </div> <div
>>>             xml:base=3D"http://www.dictionary.com/"
>>>             <http://www.dictionary.com/>> <p> <ref
>>>             target=3D"words/a.html#apple">apple</ref> </p> </div>--
>>>

--------------7772546973DFD9B20F16F996
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <p><font size=3D"-1">So, bottom line: A standalone fragment identifie=
r
        refers to the loaded document and all the <a class=3D"moz-txt-lin=
k-freetext" 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:[email protected]=
ail.com"
      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-freetex=
t" href=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-send=3D"true"
                href=3D"mailto:[email protected]" target=3D"_blank=
">[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-documen=
t
                      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_-3680229684002831364moz-txt-link-fre=
etext">xml:base</a>
                        attribute does not</b> <b>involve </b>dereferenci=
ng,
                      and XML Base processors should resolve them in the
                      usual way. In particular, <a
                        moz-do-not-send=3D"true"
                        class=3D"m_-3680229684002831364moz-txt-link-freet=
ext">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-freet=
ext">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:base=3D</a>""
                  and <a moz-do-not-send=3D"true"
                    class=3D"m_-3680229684002831364moz-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-freet=
ext">xml:base</a>.
                      <div><br>
                      </div>
                      <div>Put another way, @<a moz-do-not-send=3D"true"
                          class=3D"m_-3680229684002831364moz-txt-link-fre=
etext">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 assum=
ed the
                        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
                            moz-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-=
send=3D"true" class=3D"m_-3680229684002831364m_-7516606003097729134moz-tx=
t-link-freetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_-3=
680229684002831364m_-7516606003097729134moz-txt-link-rfc2396E" href=3D"ht=
tp://www.myteiproject.com/" target=3D"_blank">"http://www.myteiproj<wbr>e=
ct.com/"</a>
  &lt;div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7=
516606003097729134moz-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_=
-7516606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=
=3D</a><span class=3D"m_-3680229684002831364m_-7516606003097729134m_-1417=
418399130310658moz-txt-link-rfc2396E">"<a moz-do-not-send=3D"true" class=3D=
"m_-3680229684002831364m_-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_=
-7516606003097729134m_-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-se=
nd=3D"true" class=3D"m_-3680229684002831364m_-7516606003097729134moz-txt-=
link-freetext">xml:base</a> had any necessary relation to the current doc=
ument. I thought 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=
">On 5/3/2017 3:42 PM, Hugh Cayless wrote:
</div><blockquote type=3D"cite"><div dir=3D"ltr">Well, we don't know abou=
t the third one, except that it points to whatever element *in the same d=
ocument* has the @<a moz-do-not-send=3D"true" class=3D"m_-368022968400283=
1364m_-7516606003097729134moz-txt-link-freetext">xml:id</a> "apple". When=
 an application attempts to dereference it, it should make the URI in @re=
f absolute and check it against the base (<a moz-do-not-send=3D"true" cla=
ss=3D"m_-3680229684002831364m_-7516606003097729134gmail-m_-14174183991303=
10658moz-txt-link-rfc2396E" href=3D"http://www.dictionary.com/words/a.htm=
l" style=3D"white-space:pre-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 go 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. McCask=
ey <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true" href=3D"mailto:mailb=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</=
span> wrote:
<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=
 all resolve=20
to the same <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_=
-7516606003097729134m_-1417418399130310658moz-txt-link-freetext" href=3D"=
http://www.dictionary.com/words/a.html#apple" target=3D"_blank">http://ww=
w.dictionary.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_-=
3680229684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-li=
nk-freetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D"m_-36802=
29684002831364m_-7516606003097729134m_-1417418399130310658moz-txt-link-rf=
c2396E" 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_-7=
516606003097729134m_-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_-751=
6606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D<=
/a><a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75166060=
03097729134m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://ww=
w.dictionary.com/words/" target=3D"_blank">"http://www.dictionar<wbr>y.co=
m/words/"</a>&gt;
    &lt;p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7=
516606003097729134m_-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_-751=
6606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D<=
/a><a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75166060=
03097729134m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://ww=
w.dictionary.com/words/a.html" target=3D"_blank">"http://www.dictionar<wb=
r>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_-751=
6606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D<=
/a><a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-75166060=
03097729134m_-1417418399130310658moz-txt-link-rfc2396E" href=3D"http://ww=
w.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_-75166060030977=
29134HOEnZb"><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>
</body></html>
--------------7772546973DFD9B20F16F996--