Re: @xml:base with @rendition (and maybe other pointers)
"John P. McCaskey" <[email protected]> Wed, 3 May 2017 09:28:56 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
There should be renditions on born-digital documents, but they should=20 express the authors=E2=80=99 decisions about the particular document. Int= ernal=20 renditions embed those decisions in the document, as they should.=20 Corpus-wide publication standards should be implemented with external=20 stylesheets, not external renditions. Best practice would be to use born-digital renditions only where needed=20 to present the content accurately. Disallowing external renditions would help maintain the separation=20 between document-specific content and corpus-wide formatting. I would not support external renditions if it creates even a tiny burden=20 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 re= ndered 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 formatte= d, >>> not how a TEI document should be presented. >> Absolutely. >> >>> Someone will say, =E2=80=9CI want an external renditions file so I ca= n 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 shou= ld >>> 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> = and @rendition for such documents on the basis that there's no original s= ource 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 c= an imagine all sorts of exceptions (such as quotations from primary sourc= es 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 xm= l: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 thos= e >>>> 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 respec= t >>>>>> 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 medi= a >>>>> 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 point= s >>>>>> 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 sa= y >>>>>> that fragment IDs should honor the xml:base. But then again, I'm n= ot >>>>>> 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 specif= ic to an element, not to >>>>>>> the document? >>>>>>> >>>>>>> If so, the passage quoted is not saying that fragment IDs can poi= nt >>>>>>> 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 XM= L >>>>>>> element. >>>>>>> >>>>>>> Doesn=E2=80=99t this paragraph <https://www.w3.org/TR/xmlbase/#ma= tching> >>>>>>> say fragment IDs should honor the complete xml:base value in effe= ct >>>>>>> for the attribute=E2=80=99s element?