Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Wed, 3 May 2017 08:08:37 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------9BBF18618C5F06B4148A17EE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I started this because of a multi-purpose stylesheet I have. I think I=E2=80=99ll keep the bug and promote it as a feature: =E2=80=9CExternal renditions are not supported; renditions ignore xml:bas= e. So=20 go ahead and encode with local file names throughout your document.=20 Later when you deploy, use xml:base to set a root directory for those=20 files and your renditions won=E2=80=99t get messed up.=E2=80=9D -- John On 5/2/2017 5:39 PM, Hugh Cayless wrote: > > On May 2, 2017, at 17:07, Syd Bauman <[email protected]=20 > <mailto:[email protected]>> wrote: > >> Hugh -- >> >> Where does it say the interpretation of a fragment ID *with respect >> to its @xml:base* depends on the media type? > > I don't believe it does. I was looking at things like=20 > https://www.w3.org/TR/fragid-best-practices/, which says that the=20 > behaviors with regard to fragment references depend on the media type.=20 > To be sure, I'm not certain we'd actually be free to define a custom=20 > behavior for fragment ids because we have to follow the behaviors=20 > defined for XML. They're thinking particularly of cases where you=20 > might not have the whole file. > > I can't see how we could insist #word-type URIs would result in the=20 > retrieval of a different document. As Michael says, the assumption is=20 > that you've already got the referenced document, even if the base=20 > points to a different one. >> >> John -- >> >> Yes, I think a base URI is specific to an element (which might be the >> whole document, might not). >> >> Yes, I think the quoted passage is saying that a fragment ID points >> to the same document as the base URI in effect. >> >> No, I'm not at all sure the paragraph in the xml:base spec does say >> that fragment IDs should honor the xml:base. But then again, I'm not >> at all sure it *doesn't* say that. > > I can't read RFC >> >>> In XML, isn=E2=80=99t =E2=80=9Cbase URI=E2=80=9C something specific t= o an element, not to >>> the document? >>> >>> If so, the passage quoted is not saying that fragment IDs can point >>> only to the document they are in, just that a fragment ID points to >>> the same document as the base URI in effect for the containing XML >>> element. >>> >>> Doesn=E2=80=99t this paragraph <https://www.w3.org/TR/xmlbase/#matchi= ng> >>> say fragment IDs should honor the complete xml:base value in effect >>> for the attribute=E2=80=99s element? --------------9BBF18618C5F06B4148A17EE 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 started this because of a multi-purpose stylesheet I have.</font></p> <p><font size=3D"-1">I think I=E2=80=99ll keep the bug and promote it= as a feature:</font></p> <p><font size=3D"-1">=E2=80=9CExternal renditions are not supported; renditions ignore <a class=3D"moz-txt-link-freetext" href=3D"xml:= base">xml:base</a>. So go ahead and encode with local file names throughout your document. Later when you deploy, use <a class=3D"moz-txt-link-freetext" href=3D"xml:base">xml:base</a>= to set a root directory for those files and your renditions won=E2=80=99t get messed up.=E2=80=9D</font></p> <p><font size=3D"-1">-- John<br> </font></p> <font size=3D"-2"><br> </font> <div class=3D"moz-cite-prefix"><font size=3D"-2">On 5/2/2017 5:39 PM, Hugh Cayless wrote:</font><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><span></span></div> <div> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"> <div><br> </div> <div>On May 2, 2017, at 17:07, Syd Bauman <<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]">s.bauman@NORTHEASTE= RN.EDU</a>> wrote:<br> <br> </div> <blockquote type=3D"cite"> <div><span>Hugh --</span><br> <span></span><br> <span>Where does it say the interpretation of a fragment ID *with respect</span><br> <span>to its @<a class=3D"moz-txt-link-freetext" href=3D"xml:= base*">xml:base*</a> depends on the media type?</span><br> </div> </blockquote> <div><br> </div> I don't believe it does. I was looking at things like=C2=A0<a moz-do-not-send=3D"true" href=3D"https://www.w3.org/TR/fragid-best-practices/">https://w= ww.w3.org/TR/fragid-best-practices/</a>, which says that the behaviors with regard to fragment references depend on the media type. To be sure, I'm not certain we'd actually be free to define a custom behavior for fragment ids because we have to follow the behaviors defined for XML. They're thinking particularly of cases where you might not have the whole file.=C2=A0</div> <div><br> </div> <div>I can't see how we could insist #word-type URIs would result in the retrieval of a different document. As Michael says, the assumption is that you've already got the referenced document, even if the base points to a different one.=C2=A0<br> <blockquote type=3D"cite"> <div><span></span><br> <span>John --</span><br> <span></span><br> <span>Yes, I think a base URI is specific to an element (which might be the</span><br> <span>whole document, might not).</span><br> <span></span><br> <span>Yes, I think the quoted passage is saying that a fragment ID points</span><br> <span>to the same document as the base URI in effect.</span><= br> <span></span><br> <span>No, I'm not at all sure the paragraph in the <a class=3D= "moz-txt-link-freetext" href=3D"xml:base">xml:base</a> spec does say</span><br> <span>that fragment IDs should honor the <a class=3D"moz-txt-= link-freetext" href=3D"xml:base">xml:base</a>. But then again, I'm not</span><br> <span>at all sure it *doesn't* say that.</span><br> </div> </blockquote> <div><br> </div> I can't read RFC=C2=A0<br> <blockquote type=3D"cite"> <div><span></span><br> <blockquote type=3D"cite"><span>In XML, isn=E2=80=99t =E2=80=9C= base URI=E2=80=9C something specific to an element, not to</span><br> </blockquote> <blockquote type=3D"cite"><span>the document?</span><br> </blockquote> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>If so, the passage quoted is not saying that fragment IDs can point</span><br> </blockquote> <blockquote type=3D"cite"><span>only to the document they are in, just that a fragment ID points to</span><br> </blockquote> <blockquote type=3D"cite"><span>the same document as the base URI in effect for the containing XML</span><br> </blockquote> <blockquote type=3D"cite"><span>element.</span><br> </blockquote> <blockquote type=3D"cite"><span></span><br> </blockquote> <blockquote type=3D"cite"><span>Doesn=E2=80=99t this paragrap= h <<a moz-do-not-send=3D"true" href=3D"https://www.w3.org/TR/xmlbase/#matching">https:= //www.w3.org/TR/xmlbase/#matching</a>></span><br> </blockquote> <blockquote type=3D"cite"><span>say fragment IDs should honor the complete <a class=3D"moz-txt-link-freetext" href=3D"x= ml:base">xml:base</a> value in effect</span><br> </blockquote> <blockquote type=3D"cite"><span>for the attribute=E2=80=99s e= lement?</span><br> </blockquote> </div> </blockquote> </div> </blockquote> <br> </body> </html> --------------9BBF18618C5F06B4148A17EE--