Hi James Thanks, yes, you are right in thinking I had missed the definitions (they are right at the end of the file...) and also the nuance that you are proposing we make the Simple ODD itself the vector by which they are transmitted. It's not quite right, since of course the Simple ODD is not itself a Simple-conformant document (and cannot be), but It Just Might Work. L On 29/06/16 16:50, James Cummings wrote:
Hi Lou,
I think you are still misunderstanding the suggestion I made by private email earlier, so let me spell it out more.
1) There is CSS defined for these private URI values at https://github.com/TEIC/TEI/blob/tei-simple/P5/Exemplars/tei_simple.odd#L630... but yes, they aren't in <rendition> statements in the header.
2) I suggest that add a <listPrefixDef> and <prefixDef> into the TEI Simple ODD, as well as appropriate <rendition> elements in the header of the TEI Simple ODD. Thus simple:allcaps would get a rendition of:
<rendition xml:id="allcaps">text-transform: uppercase;</rendition>
And the <prefixDef> for simple would point to the release version of the TEI Simple ODD and the xml:id after it. e.g. <prefixDef ident="simple" matchPattern="([a-Z]+)" replacementPattern="http://www.tei-c.org/whatever/the/path/is/tei_simple.odd#$1"/>
3) We then also document in prose that the simple: private URI refers to these rendition values in the TEI Simple ODD.
This makes sense to me. If I knew nothing about TEI Simple, but knew that it provided these values, then I would go look at the ODD to see what those values meant.
I understand you'll object that this TEI Simple prefixDef then needs to be in every Simple document, and indeed we could add it to the oxygen TEI Simple template. Having them defined like this in the ODD makes them a much less worrying form of magic.
-James
On 29/06/16 14:57, Lou Burnard wrote:
This is a tricky one, so please bear with me and read to the end before rolling eyes.
In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p>
Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like:
<prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/>
So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI.
Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this:
<valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem>
So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute...
It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user.
At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ?
And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)