Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Wed, 3 May 2017 09:50:58 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <CAObhq+cq9xbUn5OyD6CpVY4sROebnZkYJhvHyxOYkZSYY6EeVA@mail.gmail.com> |
--94eb2c0c52e83ec277054e9ef294 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 https://github.com/TEIC/TEI/issues. 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. On Wed, May 3, 2017 at 9:28 AM, John P. McCaskey <[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. Int= ernal > 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 t= o > present the content accurately. > > Disallowing external renditions would help maintain the separation betwee= n > document-specific content and corpus-wide formatting. > > I would not support external renditions if it creates even a tiny burden > elsewhere. > > -- > > > 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]> 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 renditions 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 shoul= d >>>> 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 surel= y >>> 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> a= nd >>> @rendition for such documents on the basis that there's no original sou= rce >>> 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 correctl= y >>> (i.e. identify what everything _is_), and then the rendering should app= ly >>> the appropriate formatting based on the journal's house style. But one = can >>> imagine all sorts of exceptions (such as quotations from primary source= s >>> 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; renditions 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]>> 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 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 i= s >>>>>> 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 t= he >>>>>>> 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 no= t >>>>>>> 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 poin= t >>>>>>>> only to the document they are in, just that a fragment ID points t= o >>>>>>>> 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/#mat= ching> >>>>>>>> say fragment IDs should honor the complete xml:base value in effec= t >>>>>>>> for the attribute=E2=80=99s element? >>>>>>>> >>>>>>> --94eb2c0c52e83ec277054e9ef294 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Are you arguing that the Guidelines should add language an= d/or constraints forbidding externally-defined renditions? Or just saying t= hat you won't support them in your application? The latter is absolutel= y fine, of course. If you mean the former, I'd recommend you open an is= sue at=C2=A0<a href=3D"https://github.com/TEIC/TEI/issues">https://github.c= om/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 ha= ve 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 <spa= n dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[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 s= hould 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 styl= esheets, 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 el= sewhere.<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:1p= x #ccc solid;padding-left:1ex"> I might argue that in the case of a born-digital document, since it *is* th= e 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:1p= x #ccc solid;padding-left:1ex"> On May 3, 2017, at 08:34, Martin Holmes <<a href=3D"mailto:mholmes@UVIC.= CA" target=3D"_blank">[email protected]</a>> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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:1p= x #ccc solid;padding-left:1ex"> Someone will say, =E2=80=9CI want an external renditions file so I can easi= ly<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 dig= ital edition as similarly as possible to the original; this is surely not a= busive. 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 sour= ce that's being described?<br> <br> I don't necessarily disagree with this; there's a reasonable argume= nt 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 source= s inside the article).<br> <br> Cheers,<br> Martin<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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:1p= x #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 xml:base.= So<br> go ahead and encode with local file names throughout your document.<br> Later when you deploy, use xml:base to set a root directory for those<br> files and your renditions won=E2=80=99t get messed up.=E2=80=9D<br> <br> -- John<br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #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 href=3D"mailto:s.bauman@NORTHEA= STERN.EDU" target=3D"_blank">[email protected]</a><br> <mailto:<a 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:1p= x #ccc solid;padding-left:1ex"> Hugh --<br> <br> Where does it say the interpretation of a fragment ID *with respect<br> to its @xml:base* depends on the media type?<br> </blockquote> I don't believe it does. I was looking at things<br> like <a href=3D"https://www.w3.org/TR/fragid-best-practices/" rel=3D"norefe= rrer" 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:1p= x #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 xml:base spec does say<br> that fragment IDs should honor the xml:base. 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:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin: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 e= lement, 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 href=3D"https://www.w3.org/TR/xmlbase= /#matching" rel=3D"noreferrer" target=3D"_blank">https://www.w3.org/TR/xmlb= ase<wbr>/#matching</a>><br> say fragment IDs should honor the complete xml:base value in effect<br> for the attribute=E2=80=99s element?<br> </blockquote></blockquote></blockquote></blockquote></blockquote></blockquo= te></blockquote> </div></div></blockquote></div><br></div> --94eb2c0c52e83ec277054e9ef294--