TEI Technical Council Meeting,

Wednesday 19 September 2012

Present:

Location: IT Services, 13 Banbury Road, Oxford, OX2 8NP - Kennet Room

09:30 - 10:30

10:30 - 12:30

Ticket Breakout Groups

http://wiki.tei-c.org/index.php/Council-ticketTriage

Tickets not requiring discussion

Initial plenary discussion of Green tickets. Four tickets at the top required no discussion, they just need to be completed by those to whom they are assigned:

Previously ungrouped green tickets

biblFull, while it is in bibl and biblStruct). This ticket is assigned to KH. He no longer supports making any change to the Guidelines, and any change would break backwards compatibility or would multiply encoding options to no purpose. idno is allowed in publicationStmt, and that’s where it belongs. Action on KH: close http://purl.org/TEI/FR/3553304.

Amber tickets

to (as pointers) part of a class). LB is not convinced that any of the uses of from and to could be put into a class. Assigned to LB to clarify the wording in the Guidelines. Action on LB: Propose new wording for Guidelines per http://purl.org/TEI/FR/3496494.

12:30 - 13:30: Lunch

13:30 - 15:00

Report on TEI ODD Workshop; ODD Proposals (JC/SR)

The committee discussed all the points in the summary report at http://www.tei-c.org/Activities/Council/Working/tcw26.xml. The next action is for JC and Laurent Romary to coordinate the production of one or more papers for the Proceedings of DH 2012 laying out all the options discussed and proposing implementation plans for the high-priority items. The original meeting notes and the summary will be converted into TEI by JC. *Action on KH: KH will find a place to put ODD meeting notes and summary, probably in TCW.*Action on JC: Convert TEI ODD meeting notes and summary to TEI and put on website; Liaise with Laurent Romary and other participants about a possible publication of a summary article for Proceedings of DH 2012.

Resolving Durand Conundrum: c.f. (LB)

LB explained his Foxglove hypothesis (http://foxglove.hypotheses.org/368), and MH and JC are interested in helping to work on it. SR is concerned about the redirection of resources into this effort when other priorities are more urgent. MH wondered if this should constitute the beginning of P6 development, but LB and JC argued that this is neither necessary nor perhaps justifiable according to the Birnbaum doctrine which says Such transitions [between major PX versions] should happen only in response to the emergence of new technologies (e.g., the transition from SGML to XML) or the development of a new architecture that conveys substantial benefit (e.g., the development of the new class system) and that this wasn’t a new architecture, just an extension of it. Council discussed the issue of whether this should be a priority or not, and it does not seem to be the case that there is any comparably long-term and large-scale project except for the proposed Roma rewrite. KH raised the issue of any changes to existing schema languages -- how would such changes be reflected in our own language? JC, SR, MH and LB claim that any new, advantageous additions to any of the existing schema languages could easily be adopted into our TEI language. We could benefit greatly from being able to support more aspects of XML Schema, which is widely used in the commercial sector -- for example, the ability to constrain content models differently in different contexts, which is possible in XML Schema but not in RelaxNG. In theory, you can already put XML Schema into a content model, and it would be valid, but it wouldn’t actually cause anything to happen because our processors are only expecting RelaxNG. Council in principle approves this form of resolution of the so-called Durand Conundrum, and awaits LB’s more detailed proposal or ODD. Action on LB: develop his Durand Conundrum paper into a specific set of proposals for a new content structure, so that we can then take that to the larger ODD-implementing community for work and feedback.

XPointer Proposal (GB)

Hugh Cayless's proposal is available here: https://docs.google.com/document/d/1JsMA-gOGrevyY-crzHGiC7eZ8XdV5H_wFTlUGzrf20w/edit. GB proposes that we postpone this conversation, because there were objections and questions in the teleconference about it, and the working group has not had time to respond to those. Action on All Council: Council members (e.g. PB, LB and GB) will add comments directly to HC’s original proposal by the end of October, and then we will be happy to receive any further drafts of it.

15:00 - 17:30

Ticket Breakout Groups

location). Assigned to SR to implement what is summarized in KH’s post on the ticket from April 16. Action on SR: Implement KH's recommendations from 2012-04-16 in http://purl.org/TEI/Bug/3440771.

signed a block of things which can consist of a list of names etc., or is it the signature itself? Council concludes that this should be dealt with by moving

signed from macro.phraseSeq to macro.paraContent (though that should be double-checked at time of implementation). BB makes the point that the examples have a range of different and conflicting examples, and none of them contain list, but LB holds that the examples should be left alone until the div.liminal working group reports on usage of signed by PS and LB is complete. Assigned to SR. Action on SR: change the content model of signed to macro.paraContent, check for unexpected side-effects, and rationalize all current examples to a single practice and add one with list inside signed (see http://purl.org/TEI/Bug/3439980).

type. Council policy has been that when att.typed is requested on an element, this should be considered if it is repeatable and has clear use-cases where it would be classified. Assigned to GB to implement. Action on GB: add msDesc to att.typed per http://purl.org/TEI/FR/3526114.

state. The solution may be to make all the statelike things available in

list, and make list available in person and friends. GB: This would give rise to some oddities that we don’t currently have, such as

country in person. Another approach is to answer the use-case with standoff markup, pointing to elements external to the person element or inside it. Many people are uncomfortable with using the generic list for this, because it would generalize the oddities to lots of other contexts. So the two options are to create a generic listState, and use Schematron and Guidelines recommendations to say that only the logical state- and trait-like elements can occur within it when it’s person or place etc.; and to create separate

listPersonState and listPlaceState etc. elements, each of which has a separate content model and can occur only in a specific context. None of the proposed solutions seems to be universally popular. GB: leaving aside the name of the element, events, traits and states can all occur within a person element, but there is no useful way to group them; that’s really all we need. Are we talking about a list or a group here? RW: These groupings don’t seem like lists or groups. PB: We may as well just use list, because it would be less prescriptive. GB: We should go back to the original proposal of listState, available in person,

place and org, and allow it to contain all the elements allowed inside the parent element. GB: Since it may be important to group these elements in ways which overlap, linkGrp and link may be more appropriate. This is available inside person. JC: it’s not yet available in place,

org and event, so that should be remedied. Action: Respond with the suggestion to use linkGrp and link, and add linkGrp and

link to place, org and event. We’ll discuss how to do that in the next ticket. Assigned to PB. Action on PB: add link/linkGrp to place, org and event per http://purl.org/TEI/FR/3060867.

bibl and imprint). KH: if we agree with MH’s use case, we should add

sponsor and funder to editionStmt and to monogr. No objections were raised. LB: if the content models had respStmt changed to

model.respLike the desired outcome would happen. KH: This will work for

editionStmt, but this might give rise to a non-deterministic content model in the case of monogr, so in that case we need to add sponsor and

funder manually. LB: There is a simpler way: rationalize the content model of

monogr. But this is not a simple task; monogr is a bit of a mess. We could try replacing the parts of the content model that include respStmt with

model.respLike. Assigned to KH to implement. *Action on KH: replace respStmt with model.respLike in

editionStmt; then review monogr with the idea of simplifiying it and including model.respLike per http://purl.org/TEI/bug/3439587.*

19:30: Supper

Supper: http://www.al-shami.co.uk/ (Middle Eastern

Thursday 20 September 2012

Present:

Location: Buttery, Wolfson College, Linton Road, Oxford, OX2 6UD

(Joined by Elena Pierazzo, Chair of the TEI)

09:45 - 11:00

JC welcomed EP to the Council meeting.

Roma Templates and Example Customizations

Div.Liminal (LB)

divs.*

LingSIG issues (PB)

11:00 - 12:30

Ticket Processing

12:30 - 13:30: Lunch

13:30 - 15:00

Board Proposals for Council Consideration (EP)

Documentation on writing ODDs

15:00 - 16:30

Ticket Breakout Groups

16:30 - 17:30: Discussion and supper plans

Friday 21 September 2012

Present:

Location: Buttery, Wolfson College, Linton Road, Oxford, OX2 6UD

09:30 - 10:30

Financial issues

How much does the Council have left in its budget, and what should we do with it? Options are to save it for travel next year, when budgets will shrink; donate it back to the main budget; or use it for a code bounty for e.g. Roma rewrite (for which we might apply to the ALLC for matching funds).

Code Bounties

Code Bounties as possibility for money Council has saved through tight budgeting, institutional contributions, and savings because of agglomeration of current Council members:

Options for freezing and/or archiving Lite

LB has spent considerable time bringing Lite up to date, and now wants to publicize the up-to-date version. Options for freezing Lite:

SR: this (the last) is the way we’ve been doing it for years. JC: This is why it got so out of date. We should freeze it and point at a static version. SR: That leaves us in the situation that a Lite version available through Oxygen may have an element or attribute that is at significant variance from the current version of TEI it’s distributed with. LB: One of the features of the TEI that we advertise is the possibility of building a schema against a previous version of the TEI. SR: That’s great, but it’s different from distributing such a schema as an official TEI product. MH: We could actually decide not to freeze it; it’s not very onerous to maintain it. KH: The same arguments apply to TEI Tite. JC: So it seems that we’re reversing our decision from Ann Arbor (2012-04) on Lite and Tite which was that we didn’t want to take on the maintence burdern of Lite. KH: It seems odd that the TEI would give up on its entry-level tutorial customization, which is one of its most popular ones. The big advantage of the Lite prose is that it’s a manageable overview of the salient features of TEI. SR: Perhaps freezing should mean freezing of the intellectual effort that gave rise to the original subset. Conclusion: we reverse our decision to freeze Lite, and will instead continue to build it with every release, as well as making an effort to keep the documentation up to date. This applies to Tite as well. In the release notes for the next version we will note that the prose has been brought up to date, and that the naming convention has changed.

Move TEI to GitHub?

Already discussed: we might think about separating out the Guidelines from other stuff, so individual scripts may end up on GitHub under other people’s control. There is an ongoing action for SR to gradually remove his non-Guidelines-related tools and utilities from the main repository, for the sake of clarity. RW: We also discussed the issue of moving to Git within SF; this might give us some advantages in terms of multiple repos or sub-repos. MH: Can someone be tasked with investigating all the features of Git on SF and GitHub, as well as the possibilities for granularity of permissions in SF’s Subversion, so we can answer these questions definitively? KH: It would be a good goal that everything not essential to the Guidelines should be in a separate repository, which lots of people could have access to, without the possibility of breaking the Guidelines tools. SR: My current plan is to cut back what is already there, and then fork it when it’s minimal Guidelines-only material. GB: Once this is done, we probably do have a reason to be working with Git. Action on SR: SR will continue his work to pare down the repository and remove non-Guidelines-related material.

Deprecation of TEI P4

JC: The community has been warned previously that P4 is due to be deprecated, and now we need to take the steps necessary to enact that, such as remove its prominence from the website from November 2012. LB: An informal survey of well-known TEI projects shows that about 90% of them are still using P4. PS: Is it possible to generate a P4 schema now, using available tools? MH: PizzaChef still works, and is linked on the TEI website. JC: Existing P4 DTDs will continue to work, and Guidelines will still be available (from the Vault). We might as well leave PizzaChef available as long as it’s clear that it’s not supported. PB: P4 should definitely be removed from the Oxygen package. LB: We need to have a small publicity campaign and write to a small list of people who need to be reminded again (such as oXygen). PB: Oxygen does take statistics of who is using what; we should contact George and ask him how many people are still using P4 actively. LB: Note that other XML languages don’t have more than one version available (e.g., DocBook) in

oXygen/.JC: Who else apart from SyncRO Soft and the TEI-L list should be contacted and warned? If anyone has other suggestions, let JC know. Action on JC: Contact stakeholders to remind them of upcoming TEI P4 deprecation; notify TEI-L community; Liaise with KH and David Sewell (TEI-C Webmaster) on changes to website.

10:30 - 12:30

Ticket Breakout Groups

quotation. PB and BB are reluctant to remove quotation. Aside:

form is deprecated, but the prose doesn’t say so. GB: Should we have a

punctuation element that contains quotation? PS & GB: This should be repeatable because different punctuation might be handled differently. LB: this (like other sibling elements) need not be machine-processable; that would be difficult to do. *Action on RW and LB:define a new element called

punctuation which is a member of model.encodingDescPart

model.editorialDeclPart and

att.declarable, with prose content, and some attribute(s) defining the handling of punctuation marks. It should be repeatable.*

rend or the putative style. Action on PS: expand the Guidelines with more examples of the use of list/ type, including some which use the putative style attribute; add a section to the P6 Development page to initiate discussion of future values.

12:30 - 13:30: Lunch

13:30 - 17.30

Experimental modules, lists of customizations, etc.

This arises out of a discussion in early September on the tei-council list.

Roma interface, supported customizations and documentation

Review of the changes to the Roma front page

The Council drafted and redrafted the wording of the options on the first page of Roma. Changes were made in an effort to clarify the differences between working on a basic template and working on an existing complete customization such as Lite. It was also decided that the link to community customizations on the Roma front page should actually point to the Guidelines/Customizations page on the TEI website, rather than to the community customizations on the wiki page, which has some obsolete customizations, and is not informative enough to be useful. Action on KH: Improve TEI-C Website page on customizations.

Ticket Processing

code should be defined as a pointer to some kind of external category or to a

category element. A new ticket should be raised for this.* SR: The use of these attributes duplicates the purpose of

key and ref. This problem exists elsewhere (e.g. socEcStatus), so someone needs to look at the issue more generally. *Action on JC: While working on

person, name etc. in another ticket, examine the parallelism between scheme, code, key and ref.*

Guidelines section on encoding text directionality.*

adhoc, since such a class would be neither an attribute class nor a model class, but other than that, nothing disruptive would result, and a full description of what is meant by the categorization could be supplied in the classSpec. If at some point you wanted to do something with the class, you could make use of it in your schemaSpec, and change its type from adhoc to something else. LB feels this proposal is too vague to be useful because of the absence of use-cases. Action on JC: add more use-cases to http://purl.org/TEI/FR/3547558.