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

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

modest proposal for simplifying procmod
by Lou Burnard 23 Jan '16

23 Jan '16

The <param> element currently declares its content to be "macro.xpath" -- i.e. it can contain only an XPath. It would be a lot easier to enforce this constraint if the content were supplied as an attribute, e.g. "value" so, eg, instead of <param name="foo">@bar</param> <param name="default">corr</param> <param name="lang">ancestor::*/@xml:lang</param> <param name="place">'foot'</param> I suggest <param name="foo" value="@bar"/> <param name="default" value="corr"/> <param name="lang" value="ancestor::*/@xml:lang"/> <param name="place" value="'foot'"/> Anyone got strong feelings against this change? The @place example looks a bit dodgy, but otherwise it seems a fairly benign enhancement.

5 11

Teleconference 2015-01 - Invitation to edit
by Hugh Cayless (via Google Docs) 20 Jan '16

20 Jan '16

I've shared an item with you: Teleconference 2015-01 https://docs.google.com/document/d/1sJgb6aQVJUTs0ENyRSIMfZODtrhXeOSyKoPYrM0… It's not an attachment -- it's stored online. To open this item, just click the link above. A draft agenda for our meeting on the 25th at 09:00 EST / 14:00 GMT / 15:00 CET is available at https://docs.google.com/document/d/1sJgb6aQVJUTs0ENyRSIMfZODtrhXeOSyKoPYrM0… Please feel free to add agenda items if there's additional stuff you want to talk about.

1 0