Re: @xml:base with @rendition (and maybe other pointers)
Hugh Cayless <[email protected]> Wed, 3 May 2017 08:50:11 -0400
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
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 w= ith @rendition.=20 Sent from my phone.=20 > On May 3, 2017, at 08:34, Martin Holmes <[email protected]> wrote: >=20 >> On 2017-05-03 05:26 AM, John P. McCaskey wrote: >> Another reason to design for internal renditions only: >>=20 >> Renditions are supposed to indicate how a source document is formatted, >> not how a TEI document should be presented. >=20 > Absolutely. >=20 >> Someone will say, =81gI want an external renditions file so I can easily >> change the formatting of, say, <head> elements on all my TEI files.=81g B= ut >> that is to misuse <rendition>. Renditions are supposed to be >> document-specific. There is an argument that external renditions should >> be positively disallowed. >=20 > I often use the rendition descriptions in a document to try to render a di= gital 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 j= ournal 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 bein= g described? >=20 > 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. i= dentify what everything _is_), and then the rendering should apply the appro= priate formatting based on the journal's house style. But one can imagine al= l sorts of exceptions (such as quotations from primary sources inside the ar= ticle). >=20 > Cheers, > Martin >=20 >> Corpus-wide formatting changes should be done with stylesheets, not >> external rendition pointers. >>=20 >> -- >>=20 >>=20 >>> On 5/3/2017 8:08 AM, John P. McCaskey wrote: >>>=20 >>> I started this because of a multi-purpose stylesheet I have. >>>=20 >>> I think I=81fll keep the bug and promote it as a feature: >>>=20 >>> =81gExternal renditions are not supported; renditions ignore xml:base. S= o >>> 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=81ft get messed up.=81h >>>=20 >>> -- John >>>=20 >>>=20 >>>> On 5/2/2017 5:39 PM, Hugh Cayless wrote: >>>>=20 >>>> On May 2, 2017, at 17:07, Syd Bauman <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>=20 >>>>> Hugh -- >>>>>=20 >>>>> Where does it say the interpretation of a fragment ID *with respect >>>>> to its @xml:base* depends on the media type? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>>=20 >>>>> John -- >>>>>=20 >>>>> Yes, I think a base URI is specific to an element (which might be the >>>>> whole document, might not). >>>>>=20 >>>>> Yes, I think the quoted passage is saying that a fragment ID points >>>>> to the same document as the base URI in effect. >>>>>=20 >>>>> 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. >>>>=20 >>>> I can't read RFC >>>>>=20 >>>>>> In XML, isn=81ft =81gbase URI=81g something specific to an element, n= ot to >>>>>> the document? >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Doesn=81ft this paragraph <https://www.w3.org/TR/xmlbase/#matching> >>>>>> say fragment IDs should honor the complete xml:base value in effect >>>>>> for the attribute=81fs element? >>>=20 >>=20