- Tei-council - lists.tei-c.org

proc mod queries
by Lou Burnard 06 Feb '16

06 Feb '16

I've made a bit more progress on the "processing model" extensions to ODD proposed by the TEI Simpletons a while ago, and now have a version of P5 based on the current dev branch which includes them AND builds correctly. But I havent yet finished hacking the prose into shape, and I have some questions. Here's the first. The @output attribute "the intended output method" (that's clearly wrong though; surely it should be "the intended output target"?) is defined with a closed list of values "web", "print", and "plaintext". a) why is this a closed list? I can think of lots of other possible values e.g. "mobile device", "PDF", "text-to-speech synthesizer" for starters... b) what exactly does "plaintext" mean? And here's the zero'th. To whom if not the Council should I be addressing this query?

3 8

processing model use of CSS
by Lou Burnard 05 Feb '16

05 Feb '16

Decision please. The current description of the processing model tacitly assumes that CSS is used to express output rendition, and it's hard to see how else the job would be done, but the text of the Guidelines is rather vague on the topic. Should we say a) outputRendition *must* be expressed using CSS b) it is *recommended* that CSS be used c) we don't care what you use, but our examples assume you will use CSS If we choose b or c, we will presumably need to add some complexity to the scheme (e.g. to say what has been used instead if it's not CSS)

5 17

weird example
by Lou Burnard 05 Feb '16

05 Feb '16

The spec for <model> currently has a whole slew of examples, some of which need to go elsewhere I think. And one or two of them are entirely mysterious. This one for example: <exemplum xml:lang="en"> <egXML xmlns="http://www.tei-c.org/ns/Examples"> <model predicate="parent::choice and count(parent::*/*) gt 1" behaviour="omit"/> </egXML> </exemplum> Can someone please explain to me what this is meant to achieve? It seems to be saying "if my parent is <choice> and any of my parents has more than one child node, then suppress me". In the immortal words of Manuel, che?

3 4

outputRendition spec
by Lou Burnard 05 Feb '16

05 Feb '16

The <remarks> for this element currently read: "The <gi>outputRendition</gi> element differs from the <gi>rendition</gi> element describes rendering information in one or more possible outputs, usually recorded in the TEI customization file, the latter must only be used to document the original rendition of the source text." - As far as I know <outputRendition> can only appear inside an ODD file, so why "usually" ? - If @useSourceRendition is true, then the <rendition> element *will* affect the output. I'm proposing the following revision: This component of an element specification describes the rendering or appearance intended for all occurrences of the element in a specified context for a specified type of output. The <rendition> element, by contrast, describes the actual rendering or appearance of all occurrences of the specified element in a source document. The <att>useSourceRendition</att> attribute may however be used to indicate that formatting information provided by a <gi>rendition</gi> element is to be combined with any provided by an <gi>outputRendition</gi> element. It is strongly recommended that the W3C Cascading Stylesheet language (CSS2 or later) be used to express the required formatting information. (The second paragraph modulo whatever we decide to do about the CSS or what debate)

3 2

Proofreading processing model rewrite
by James Cummings 28 Jan '16

28 Jan '16

I'd like to thank Lou again for the rewrite of the draft section for TD that I'd done in the processing-model branch -- it is a substantial rewrite. This is at http://teic.github.io/TEI/TD.html#TDPM or if you prefer the xml https://github.com/TEIC/TEI/blob/lb42-procmod/P5/Source/Guidelines/en/TD-Do… I've given the chapter a quick skim read and my initial suggestions/thoughts are: "22.4.4.4 Processing Models" Should processing models section be a new 22.4.5? It is longer an more substantial than some of its siblings at this level. " In the present implementation, rendition is expressed using the W3C Cascading Stylesheet Language (CSS)" In which implementation? This may be confusing, perhaps just the second half of that sentence? "The intent is that these should be presented in an italic font as inline elements:" maybe: "The intent is that these elements should be presented inline in an italic font" (i.e. They may not be being processed into 'elements', that may be mistaken as suggesting this is only for HTML output or something.) You are right that at the bottom of the Output Rendition section we could say something about 'Why CSS', but this is for the same reason that we suggest elsewhere inside the <rendition> element as a formally declared stylesheet language. This might suggest that we should be having a @scheme attribute like <rendition> with css as a value? In Implementation: "If the useSourceRendition attribute on the model has the value false then any rendition attribute on the source element can be ignored; otherwise its value must be combined with that given in the outputRendition element, if any." Maybe reverse this since it might contradict what was said above in the bit on useSourceRendition? So: "If the @useSourceRendition attribute on the model has the value true then any rendition attribute in the source element must be combined with any given in the outputRendition element, otherwise all rendition attributes in the source should be ignored." -James -- Dr James Cummings, James.Cummings(a)it.ox.ac.uk Academic IT Services, University of Oxford "

4 10

screwy example (was "Re: [TEI] <lg> and <gap> (#1419)")
by Syd Bauman 25 Jan '16

25 Jan '16

Re: the 4th example in section 3.12.1, "Core Tags for Verse"[1] See file TEI/P5/Source/Guidelines/en/CO-CoreElements.xml and search for "#CO-eg-07". The example doesn't seem to exemplify what the prose is talking about at all. Looks to me like the <stage> is supposed to be a sibling of the <l>s, in between the last two. (Otherwise, the @part attributes are not needed, the last two <l> elements could just be one <l> with a <stage> inside. Which, BTW, is a less-than-optimal encoding in this case, because the stage direction doesn't scan. :-) This seems to me to be a corrigible error, which I have just fixed on my home desktop, but don't plan to push for awhile in case someone wants to object. Notes ----- [1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CO.html#COVE

1 0

Links for this morning's call
by Hugh Cayless 25 Jan '16

25 Jan '16

Agenda: https://docs.google.com/document/d/1sJgb6aQVJUTs0ENyRSIMfZODtrhXeOSyKoPYrM0… Hangout: https://hangouts.google.com/call/hpffrckgslsfz425fyzfby256ia Phone numbers are in the Agenda if you can’t connect to the Hangout.

1 0

Pure ODD
by Hugh Cayless 25 Jan '16

25 Jan '16

Dear All, Now that Lou’s tremendous work on Pure ODD has been merged into dev, we should try to give it a thorough workout. I’ve regenerated the "bleeding edge" Guidelines at http://teic.github.io/TEI/index.html <http://teic.github.io/TEI/index.html>. It would be extremely helpful if you can take the time to look it over for problems and report them as issues. I’ve experimented in that build with rearranging the order in which things are displayed. See, e.g. http://teic.github.io/TEI/ref-witDetail.html <http://teic.github.io/TEI/ref-witDetail.html>. Your reactions (whether positive or not) will be most welcome!

3 3

Chair Elections
by Hugh Cayless 25 Jan '16

25 Jan '16

Dear All, No-one has contacted me about running for chair, and I don’t believe anyone has expressed their willingness to run on-list either. Please correct me if I’m wrong! As I said in our last meeting, I’m willing to serve for another year, particularly if nobody else wants to do it, but I’d encourage you to think about it (for next year even if not this one). I may not even be on Council next year, as my term will be up at year’s end! It’s really not that bad a job, I promise :-). If anyone has questions about it, even if you’d rather wait until next year, do feel free to ask me or James (who was Chair before me) about it. Note that the deliberately vague guidelines for Chair Elections are posted here: http://wiki.tei-c.org/index.php/TEI-Council-FAQ#How_is_the_TEI_Technical_Co… <http://wiki.tei-c.org/index.php/TEI-Council-FAQ#How_is_the_TEI_Technical_Co…> —it’s one of those things I’ve never done before as Chair, and so have gotten it somewhat wrong, but I don’t want to sneak back into the position, so I’ll issue a last call for self-nominations now. My own reasons for wanting to continue are: 1) I think I sort of have it figured out now 2) My job at Duke will allow me to devote the time needed to it 3) I’d like to think things will be easier this year If anyone objects or wants to stand, then we’ll set up an election. All the best, and wishing you all a happy new year, Hugh

6 16

revised TD for procmod
by Lou Burnard 24 Jan '16

24 Jan '16

I've now made a new branch in the repo for my revised version of TD containing the processing model documentation. Some way to go yet, notably in the element specs which still seem occasionally too vague to me, and test files are still missing. But I'd appreciate some reassurance that I haven't totally misunderstood something crucial. The branch is called lb42-procmod and is based on dev as of last night

1 0