Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Thu, 4 May 2017 10:16:19 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------A7F2EDCB28142AB608D34ED8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I asked about this over at XML-DEV,=20 http://lists.xml.org/archives/xml-dev/201705/msg00008.html. Opinion there is with me and opposite the majority here. Readers there don=E2=80=99t seem to think there is anything to debate. I = got one=20 short answer and one dismissive comment about =E2=80=9Dquestions that sim= ple.=E2=80=9D=20 Someone take a look and be sure I didn=E2=80=99t word my question unfairl= y. Whichever interpretation TEI adopts, sounds like it should be documented=20 in the Guidelines or a note somewhere. If the McCaskey/XML-DEV interpretation is adopted, the GitHub issue I=20 posted about @rendition stands. If not, that issue goes away. John On 5/3/2017 8:03 PM, Hugh Cayless wrote: > Those are the cards we've been dealt, yeah. > > Sent from my phone. > > On May 3, 2017, at 19:53, John P. McCaskey <[email protected]=20 > <mailto:[email protected]>> wrote: > >> So, bottom line: A standalone fragment identifier refers to the=20 >> loaded document and all the xml:base values above it in the hierarchy=20 >> are 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=20 >>> the 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 e= mpty strings >>> and #fragments. But over here in XML-land, we don=E2=80=99t d= o >>> =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. >>> >>> >>> A note has: >>> >>> 5. The meanings of xml:base=3D"" and xml:base=3D"#frag" have >>> been 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]>> wro= te: >>>> >>>> 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"> <re= f >>>> target=3D"#apple">apple</ref> </p> </div> </div> </div> >>>> >>>> I didn=E2=80=99t think xml:base had any necessary relation t= o 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/"> >>>>> <ref 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>-- >>>>> --------------A7F2EDCB28142AB608D34ED8 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">I asked about this over at XML-DEV, <a href=3D"http://lists.xml.org/archives/xml-dev/201705/msg00008.h= tml">http://lists.xml.org/archives/xml-dev/201705/msg00008.html</a>.</fon= t></p> <p><font size=3D"-1">Opinion there is with me and opposite the majority here.<br> </font></p> <p><font size=3D"-1">Readers there don=E2=80=99t seem to think there = is anything to debate. I got one short answer and one dismissive comment about =E2=80=9Dquestions that simple.=E2=80=9D Someone ta= ke a look and be sure I didn=E2=80=99t word my question unfairly.<br> </font></p> <font size=3D"-1">Whichever interpretation TEI adopts, sounds like it should be documented in the Guidelines or a note somewhere.<br> <br> If the McCaskey/XML-DEV interpretation is adopted, the GitHub issue I posted about @rendition stands. If not, that issue goes away.<br> </font> <p><font size=3D"-1">John<br> </font></p> <p><font size=3D"-1"><br> </font></p> <br> <div class=3D"moz-cite-prefix">On 5/3/2017 8:03 PM, Hugh Cayless wrote:<br> </div> <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Du= tf-8"> <div>Those are the cards we've been dealt, yeah.=C2=A0<br> <br> Sent from my phone.=C2=A0</div> <div><br> On May 3, 2017, at 19:53, John P. McCaskey <<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]= M">[email protected]</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type"> <p><font size=3D"-1">So, bottom line: A standalone fragment identifier refers to the loaded document and all the <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"xml:base">xml:base</a> values above it in the hierarchy are irrelevant. Encoders cannot use <a moz-do-not-send=3D"true" 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><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 moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext= " href=3D"xml:base=3D">xml:base=3D</a>"#frag". It says no= thing whatever about <p rendition=3D"#foo">. I don't thin= k 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"><= ;<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>><= /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_-3680229684002831364moz-txt-li= nk-freetext">xml:base</a> attribute does not</b> <b>involve </b>deref= erencing, 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= -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=9Cderefer= encing=E2=80=9D of empty strings and #fragments. But over here in XML-land, we don=E2=80=99t do =E2=80=9Cdereferencin= g.=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. <b= r> </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-fre= etext">xml:base=3D</a>"" and <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364moz-txt-link-fre= etext">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" class=3D"m_-3680229684002831364moz-txt-li= nk-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, 201= 7 at 4:29 PM, John P. McCaskey <span dir=3D"ltr"><<a moz-do-not-send=3D"tru= e" href=3D"mailto:[email protected]= " target=3D"_blank">mailbox@johnmccaskey.= com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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"><div <a moz-d= o-not-send=3D"true" class=3D"m_-3680229684002831364m_-7516606003097729134= moz-txt-link-freetext">xml:base=3D</a><a moz-do-not-send=3D"true" class=3D= "m_-3680229684002831364m_-7516606003097729134moz-txt-link-rfc2396E" href=3D= "http://www.myteiproject.com/" target=3D"_blank">"http://www.myteiproj<wb= r>ect.com/"</a> <div <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7= 516606003097729134moz-txt-link-freetext">xml:base=3D</a>"images/"> <div> <graphic url=3D"logo.jpg"> </div> <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>> <p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_= -7516606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base= =3D</a>"a.html"> <ref target=3D"#apple">apple</ref> </p> </div> </div> </div>=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"><<a moz-do-not-send=3D"true" href=3D"mailto:mailb= [email protected]" target=3D"_blank">[email protected]</a>></= 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"><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>> <p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7= 516606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D= </a>"words/"> <ref target=3D"a.html#apple">apple</r<wbr>ef> </p> </div> <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>> <p <a moz-do-not-send=3D"true" class=3D"m_-3680229684002831364m_-7= 516606003097729134m_-1417418399130310658moz-txt-link-freetext">xml:base=3D= </a>"a.html"> <ref target=3D"#apple">apple</ref> </p> </div> <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>> <p> <ref target=3D"#apple">apple</ref> </p> </div> <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= >> <p> <ref target=3D"words/a.html#apple">ap<wbr>ple</ref> </p> </div></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> </div></blockquote> </blockquote> </body></html> --------------A7F2EDCB28142AB608D34ED8--