Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Wed, 3 May 2017 10:28:57 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------949AFC57F39D490C2B78FE06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable The burden is that it ruins the one straightforward use of xml:base =E2=80= =94=20 which is to encode file references (for images, web locations, etc.)=20 with relative names and then record (and change as needed) the absolute=20 directory location separately with an xml:base entry. I will go ahead and open a github ticket. Thanks, John On 5/3/2017 9:50 AM, Hugh Cayless wrote: > Are you arguing that the Guidelines should add language and/or=20 > constraints forbidding externally-defined renditions? Or just saying=20 > that you won't support them in your application? The latter is=20 > absolutely fine, of course. If you mean the former, I'd recommend you=20 > open an issue at https://github.com/TEIC/TEI/issues. I confess I don't=20 > really see the problem, other than that it makes implementation a=20 > little more complicated because you have to load the external document. > > On Wed, May 3, 2017 at 9:28 AM, John P. McCaskey=20 > <[email protected] <mailto:[email protected]>> wrote: > > There should be renditions on born-digital documents, but they > should express the authors=E2=80=99 decisions about the particular > document. Internal renditions embed those decisions in the > document, as they should. Corpus-wide publication standards should > be implemented with external stylesheets, not external renditions. > > Best practice would be to use born-digital renditions only where > needed to present the content accurately. > > Disallowing external renditions would help maintain the separation > between document-specific content and corpus-wide formatting. > > I would not support external renditions if it creates even a tiny > burden elsewhere. > > --=20 > > > On 5/3/2017 8:50 AM, Hugh Cayless wrote: > > I might argue that in the case of a born-digital document, > since it *is* the original, the encoder is on solid ground > saying how they want it rendered with @rendition. > > Sent from my phone. > > On May 3, 2017, at 08:34, Martin Holmes <[email protected] > <mailto:[email protected]>> wrote: > > On 2017-05-03 05:26 AM, John P. McCaskey wrote: > Another reason to design for internal renditions only: > > Renditions are supposed to indicate how a source > document is formatted, > not how a TEI document should be presented. > > Absolutely. > > Someone will say, =E2=80=9CI want an external rendition= s 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. > > I often use the rendition descriptions in a document to > try to render a digital edition as similarly as possible > to the original; this is surely not abusive. But there is > also the case of born-digital documents such as modern > journal articles. Would you want to ban the use of > <rendition> and @rendition for such documents on the basis > that there's no original source that's being described? > > I don't necessarily disagree with this; there's a > reasonable argument that says in a digitally-authored > document, you can simply tag correctly (i.e. identify what > everything _is_), and then the rendering should apply the > appropriate formatting based on the journal's house style. > But one can imagine all sorts of exceptions (such as > quotations from primary sources inside the article). > > Cheers, > Martin > > Corpus-wide formatting changes should be done with > stylesheets, not > 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; ren= ditions > ignore xml:base. So > go ahead and encode with local file names > throughout your document. > Later when you deploy, use xml:base to set a root > directory for those > 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] > <mailto:[email protected]> > <mailto:[email protected] > <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 thing= s > like > https://www.w3.org/TR/fragid-best-practices/ > <https://www.w3.org/TR/fragid-best-practices/>, > 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. > > 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. > > 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/#matchin= g > <https://www.w3.org/TR/xmlbase/#matchin= g>> > say fragment IDs should honor the > complete xml:base value in effect > for the attribute=E2=80=99s element? > > --------------949AFC57F39D490C2B78FE06 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">The burden is that it ruins the one straightforward use of <a class=3D"moz-txt-link-freetext" href=3D= "xml:base">xml:base</a> =E2=80=94 which is to encode file references (for images, web locations, etc.) </font><font size=3D"-1">with relative names </font><font size=3D"-1">and then record (and change as needed) the absolute directory location separately with an <a class=3D"moz-txt-link-freetext" href=3D"xml= :base">xml:base</a> entry.<br> </font></p> <p><font size=3D"-1">I will go ahead and open a github ticket.</font>= </p> <p><font size=3D"-1">Thanks,<br> John<br> </font></p> <p><font size=3D"-1"><br> </font></p> <br> <div class=3D"moz-cite-prefix">On 5/3/2017 9:50 AM, Hugh Cayless wrote:<br> </div> <blockquote cite=3D"mid:[email protected]= l.com" type=3D"cite"> <div dir=3D"ltr">Are you arguing that the Guidelines should add language and/or constraints forbidding externally-defined renditions? Or just saying that you won't support them in your application? The latter is absolutely fine, of course. If you mean the former, I'd recommend you open an issue at=C2=A0<a moz-do-not-send=3D"true" href=3D"https://github.com/TEIC/TEI/issues">https://github.com/= TEIC/TEI/issues</a>. I confess I don't really see the problem, other than that it makes implementation a little more complicated because you have to load the external document.</div> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Wed, May 3, 2017 at 9:28 AM, 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:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There should be renditions on born-digital documents, but they should express the authors=E2=80=99 decisions about the parti= cular document. Internal renditions embed those decisions in the document, as they should. Corpus-wide publication standards should be implemented with external stylesheets, not external renditions.<br> <br> Best practice would be to use born-digital renditions only where needed to present the content accurately.<br> <br> Disallowing external renditions would help maintain the separation between document-specific content and corpus-wide formatting.<br> <br> I would not support external renditions if it creates even a tiny burden elsewhere.<br> <br> -- <div class=3D"HOEnZb"> <div class=3D"h5"><br> <br> On 5/3/2017 8:50 AM, Hugh Cayless wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I might argue that in the case of a born-digital document, since it *is* the original, the encoder is on solid ground saying how they want it rendered with @rendition.<br> <br> Sent from my phone.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On May 3, 2017, at 08:34, Martin Holmes <<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">m= [email protected]</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 2017-05-03 05:26 AM, John P. McCaskey wrote:<br> Another reason to design for internal renditions only:<br> <br> Renditions are supposed to indicate how a source document is formatted,<br> not how a TEI document should be presented.<br> </blockquote> Absolutely.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Someone will say, =E2=80=9CI want an external rendi= tions file so I can easily<br> change the formatting of, say, <head> elements on all my TEI files.=E2=80=9C But<br> that is to misuse <rendition>. Renditions are supposed to be<br> document-specific. There is an argument that external renditions should<br> be positively disallowed.<br> </blockquote> I often use the rendition descriptions in a document to try to render a digital edition as similarly as possible to the original; this is surely not abusive. But there is also the case of born-digital documents such as modern journal articles. Would you want to ban the use of <rendition> and @rendition for such documents on the basis that there's no original source that's being described?<br= > <br> I don't necessarily disagree with this; there's a reasonable argument that says in a digitally-authored document, you can simply tag correctly (i.e. identify what everything _is_), and then the rendering should apply the appropriate formatting based on the journal's house style. But one can imagine all sorts of exceptions (such as quotations from primary sources inside the article).<= br> <br> Cheers,<br> Martin<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Corpus-wide formatting changes should be done with stylesheets, not<br> external rendition pointers.<br> <br> --<br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 5/3/2017 8:08 AM, John P. McCaskey wrote:<br> <br> I started this because of a multi-purpose stylesheet I have.<br> <br> I think I=E2=80=99ll keep the bug and promote it = as a feature:<br> <br> =E2=80=9CExternal renditions are not supported; renditions ignore <a class=3D"moz-txt-link-freete= xt" href=3D"xml:base">xml:base</a>. So<br> go ahead and encode with local file names throughout your document.<br> Later when you deploy, use <a class=3D"moz-txt-li= nk-freetext" href=3D"xml:base">xml:base</a> to set a root directory for those<br> files and your renditions won=E2=80=99t get messe= d up.=E2=80=9D<br> <br> -- John<br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 5/2/2017 5:39 PM, Hugh Cayless wrote:<br> <br> On May 2, 2017, at 17:07, Syd Bauman <<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</= a><br> <mailto:<a moz-do-not-send=3D"true" href=3D"mailto:[email protected]" target=3D"_blank">s.bauman@NORTHEASTERN.<wbr>= EDU</a>>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hugh --<br> <br> Where does it say the interpretation of a fragment ID *with respect<br> to its @<a class=3D"moz-txt-link-freetext" hr= ef=3D"xml:base*">xml:base*</a> depends on the media type?<br> </blockquote> I don't believe it does. I was looking at things<br> like <a moz-do-not-send=3D"true" href=3D"https://www.w3.org/TR/fragid-best-pra= ctices/" rel=3D"noreferrer" target=3D"_blank">https://= www.w3.org/TR/fragid-b<wbr>est-practices/</a>, which says that<br> the behaviors with regard to fragment references depend on the media<br> type. To be sure, I'm not certain we'd actually be free to define a<br> custom behavior for fragment ids because we have to follow the<br> behaviors defined for XML. They're thinking particularly of cases<br> where you might not have the whole file.<br> <br> I can't see how we could insist #word-type URIs would result in the<br> retrieval of a different document. As Michael says, the assumption is<br> that you've already got the referenced document, even if the base<br> points to a different one.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> John --<br> <br> Yes, I think a base URI is specific to an element (which might be the<br> whole document, might not).<br> <br> Yes, I think the quoted passage is saying that a fragment ID points<br> to the same document as the base URI in effect.<br> <br> No, I'm not at all sure the paragraph in the <a class=3D"moz-txt-link-freetext" href=3D"xm= l:base">xml:base</a> spec does say<br> 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<br> at all sure it *doesn't* say that.<br> </blockquote> I can't read RFC<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In XML, isn=E2=80=99t =E2=80=9Cbase URI=E2=80= =9C something specific to an element, not to<br> the document?<br> <br> If so, the passage quoted is not saying that fragment IDs can point<br> only to the document they are in, just that a fragment ID points to<br> the same document as the base URI in effect for the containing XML<br> element.<br> <br> Doesn=E2=80=99t this paragraph <<a moz-do-not-send=3D"true" href=3D"https://www.w3.org/TR/xmlbase/#ma= tching" rel=3D"noreferrer" target=3D"_blank">http= s://www.w3.org/TR/xmlbase<wbr>/#matching</a>><br> say fragment IDs should honor the complete <a class=3D"moz-txt-link-freetext" href=3D"= xml:base">xml:base</a> value in effect<br> for the attribute=E2=80=99s element?<br> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </blockquote> </div> </div> </blockquote> </div> <br> </div> </blockquote> <br> </body> </html> --------------949AFC57F39D490C2B78FE06--