Re: @xml:base with @rendition (and maybe other pointers)
Martin Holmes <[email protected]> Wed, 3 May 2017 08:20:54 -0700
| Newsgroups | gmane.text.tei.general |
|---|---|
| Message-ID | <[email protected]> |
On 2017-05-03 05: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. I would think of it as slightly more nuanced than that. The author might=20 use rendition features to describe how, in their mind, an ideal version=20 of the document would look. So you might have this (using @style for=20 simplicity): <emph style=3D"font-weight: bold;">way too big</emph> whereas the editor of journal X would be free to ignore that if the=20 journal's styleguide says that emphasized text is shown in italics, not=20 bold. The journal's style would be applied based on the <emph> tag (what=20 the text is) rather than the @style attribute (what the author asserts=20 the text should look like). The author is of course free to apply their=20 own rendition rules for a version of the document they're publishing=20 independently for some reason, outside the context of a larger volume,=20 issue, collection or whatever. Cheers, Martin > > 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 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 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; 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 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 specif= ic 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/#matching> say fragment >>>>>>> IDs should honor the complete xml:base value in effect >>>>>>> for the attribute=E2=80=99s element? >>>> >>>