Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Wed, 3 May 2017 08:26:18 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------A10EAB4E9B4E56B3D5602DC1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Another reason to design for internal renditions only: Renditions are supposed to indicate how a source document is formatted,=20 not how a TEI document should be presented. Someone will say, =E2=80=9CI want an external renditions file so I can ea= sily=20 change the formatting of, say, <head> elements on all my TEI files.=E2=80= =9C But=20 that is to misuse <rendition>. Renditions are supposed to be=20 document-specific. There is an argument that external renditions should=20 be positively disallowed. Corpus-wide formatting changes should be done with stylesheets, not=20 external rendition pointers. -- On 5/3/2017 8:08 AM, John P. McCaskey wrote: > > 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:b= ase. 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=20 >> type. To be sure, I'm not certain we'd actually be free to define a=20 >> custom behavior for fragment ids because we have to follow the=20 >> behaviors defined for XML. They're thinking particularly of cases=20 >> where you 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 = to 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/#match= ing> >>>> say fragment IDs should honor the complete xml:base value in effect >>>> for the attribute=E2=80=99s element? > --------------A10EAB4E9B4E56B3D5602DC1 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">Another reason to design for internal renditions only:<br> </font></p> <p><font size=3D"-1">Renditions are supposed to indicate how a source document is formatted, not how a TEI document should be presented. <br> </font></p> <p><font size=3D"-1">Someone will say, =E2=80=9CI want an external re= nditions file so I can easily change the formatting of, say, <head> elements on all my TEI files.=E2=80=9C But that is to misuse <rendition>. Renditions are supposed to be document-specific. There is an argument that external renditions should be positively disallowed.</font></p> <p><font size=3D"-1">Corpus-wide formatting changes should be done with stylesheets, not external rendition pointers.</font></p> <p><font size=3D"-1">--</font><br> </p> <br> <div class=3D"moz-cite-prefix"><font size=3D"-2">On 5/3/2017 8:08 AM, John P. McCaskey wrote:</font><br> </div> <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-= Type"> <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 moz-do-not-send=3D"true" 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 moz-do-not-send=3D"true" 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 P= M, 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=3Dutf-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@NORTHEAS= TERN.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 moz-do-not-send=3D"true" 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:/= /www.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 moz-do-not-send=3D"true" 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 moz-do-not-send=3D"true" 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= =9Cbase 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 i= s 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 paragr= aph <<a moz-do-not-send=3D"true" href=3D"https://www.w3.org/TR/xmlbase/#matching">http= s://www.w3.org/TR/xmlbase/#matching</a>></span><br> </blockquote> <blockquote type=3D"cite"><span>say fragment IDs should honor the complete <a moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext" href=3D"xml:base">xml= :base</a> value in effect</span><br> </blockquote> <blockquote type=3D"cite"><span>for the attribute=E2=80=99s= element?</span><br> </blockquote> </div> </blockquote> </div> </blockquote> <br> </blockquote> <br> </body> </html> --------------A10EAB4E9B4E56B3D5602DC1--