TEI Technical Council Minutes 2015-08

Teleconference 2015-08-31 14:00 UTC

Present

• Hugh Cayless (HC)
• Syd Bauman (SB)
• Peter Stadler (PWS)
• James Cummings (JC)
• Martin Holmes (MH)
• Lou Burnard (LB)

Apologies

• Stefanie Gehrke (SG)
• Raff Viglianti (RV)

• started 14:06; ended 15:51

Agenda

• Conference and F2F

  • Sunday meeting is booked in same place as business meeting in the Mama Shelter Hotel

  • The meeting will be there all day Sunday 25 October, then use the workshop venue room for Monday 26 October and first half of Tuesday 27 October

• Migration Status and Issues

  • Remember, there is a pointer to the Sourceforge repository and a TEI web page with instructions for using it on the Guidelines’ index page (Bug #766) There is also other documentation here and there which points specifically to SF. And legacy URLs which point there from many systems. We’ll have to track those down.

  • JC and MH would be reluctant to move if SF were more trustworthy. LB confirms that using Subversion on GitHub “nearly works”. HC worries about branching. All agree that if we’re moving to GitHub, we should move to git too. Those skilled with git should help those who are new to it. Practice is required. MH suggests that the repo should be called “P5” instead of “Guidelines”. PWS asks whether we’ve moved yet or not. HC: The “Guidelines” (=P5) one can, if we agree, be the repo going forward. We should use Guidelines-Test for playing around and migrating tickets. JC points out that Guidelines = TEI as it has more than P5 in it. (Action on JC: Rename Guidelines Repository on TEIC github organisation. DONE). Should we move now or wait until after a release? Some disagreement. LB and SB feel it’s vital to keep the rhythm of the releases going, and put off the migration; others fear that SF is now so unreliable that it’s justifiable to defer a release. Consensus seems to be to move to GitHub, and try to release from there, with a backup plan to push from GitHub/master to SF, and build from there. I.e., HC & MH will work on release process from GitHub for 2 weeks, and then decide which we do.

• Pure ODD and DTDs

  • Problem is that in impureODD there are some redundant <rng:group> elements inserted by the wise men of long ago to ensure that DTD generation worked correctly (i.e. had parens in right places). <rng:group> is mostly correctly translated as <sequence> in pure odd. But we have a schematron rule which prohibits <sequence>s of only one thing.

  • Simply wrapping all %model.xxx; in parens won’t work: it generates error for mixed content models

  • Trying to figure out what’s going on in odd2dtd.xsl is Hard. Very Hard. You may think diamonds, granite, or tungsten are pretty hard. They are like yoghurt in comparison to this.

  • Cunning plan — post-tweak the p5subset.xml file to add spurious <sequence> elements looks promising. LB has so far identified 92 cases which need tweaking. SB volunteers to write the hack itself.

• <xenoData> (SB):

  • categorization: <xenoData> currently has a derived @type with values “source” and “transcription”; this is wrong, as <xenoData> is repeatable and categorizable, so @type is needed for categorization; i.e., @type is where “this is hand-generated METS information” or “this Dublin Core generated by program X” should go. But where then does “source” vs “thisTEI” go? SB would prefer to create a new @about, @describes, or @scope for “source” vs “thisTEI”. General consensus in favour of @scope with suggested values of source/transcription/other?. Would also be a member of att.typed to give users the option to categorize as they need to.

  • since we’re letting non-XML data in, is an @encoding or similar necessary? (SB wonders if permitting <tei:binaryObject> as a child of <xenoData> would do the trick?) Consensus is that @encoding is not needed, at least initially.

• Abstract Model enforcement with Schematron

  • https://github.com/TEIC/TEI/commit/fc6d0e79f12e90b09c37c89200f36d453e27c10c

  • Basic point is global checking that, e.g., nowhere is there a div inside a p, and other similar things which should be true. Will support the proposed changes to the appcrit model that JC still worries about, this will stop people doing stupid stuff, hopefully, for those using schematron only

  • Need to worry about what <p>-inside-<p> situations are, in fact, aligned with abstract model (e.g., p/note/p). HC will continue implementing, but will talk to SB about how more automated Schematron generation based on the class system might be achieved. JC thinks there must be a better way we can generate this even if it involves revision of the class system. (He suggests pure ODD localisation of content models but SB says this won’t help.)

• Updates needed to language identification (SB)

  • SB informs Council the language identification parts of Guidelines need some updating — volunteers to do the work himself, but needs guidance on where (Sourceforge vs GitHub) and (if using `git`) how to create ticket, make changes, and test them.

• TEI Simple (JC)

  • JC informs Council that the TEI Simple project is working hard. He has made available draft Spec files for inclusion in the Guidelines for the Processing Model at https://github.com/TEIC/TEI-Simple/tree/master/guidelines-specs and is drafting prose to go with these for the TD chapter. It would be nice to get this in the next release. The TEI Simple customization can be added to a later release if not ready. JC is now working on the “Performance Indicators” which is a <taxonomy> with set of nested categories indicating what kinds of markup you can expect a text to have. (e.g. are there names, do they have @ref, etc.)

• Next Release? Who? When? Where? What? Why?

  • Who = a panel of experts

  • When = early–mid October; 1 October Freeze

  • Where = internet

  • What = include <xenoData>, pureODD improvements, maybe <p>-inside-<rdg>, etc.

  • Why = it’s our job

  • Release 2.9.0 Codename: Stormageddon