TEI Technical Council Meeting,

Ticket Breakout Groups

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

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.

Ticket Breakout Groups

http://purl.org/TEI/Bug/3440771 (Multiple geo tags in 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.

http://purl.org/TEI/Bug/3439980 (content model of signed). Is a 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).

http://purl.org/TEI/FR/3526114 (add type to msDesc). JC has argued that since msDesc can occur multiply in the same e.g. listBibl, you should be able to distinguish them with 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.

http://purl.org/TEI/FR/3060867 (Grouping traitlike, statelike, and eventlike elements). PB had started to implement this but got stuck when conflicts emerged between the repeated declarations of 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.

http://purl.org/TEI/FR/3536363 (rationalize content models of org and place). Discussion was diverted away from the ticket to the larger issue raised by Peter Stadler: http://sourceforge.net/mailarchive/message.php?msg_id=29144155. GB: The proposal there was to suggest that we look at those different content models, rationalize them, create a model of the things shared between them, and create a separate model for that. Action on JC: create a proposal for the changes required per http://purl.org/TEI/FR/3536363, and with reference to http://sourceforge.net/mailarchive/message.php?msg_id=29144155.

http://purl.org/TEI/FR/3504690 (floatingDiv proposal). Council had previously rejected the floatingDiv proposal as it was, asking for new examples. PS provided three more examples:

• http://www.umich.edu/~pfs/divlim/samples_2/floatdiv1.pdf
• http://www.umich.edu/~pfs/divlim/samples_2/floatdiv2.pdf
• http://www.umich.edu/~pfs/divlim/samples_2/floatdiv3.pdf

but Council still did not find these more convincing than the earlier ones. The Council generally agrees with the comment on the ticket to the effect that there is not enough convincing evidence for the need for floatingDiv, and will close the ticket pending any new concrete submissions. JC to close ticket. Action on JC: close http://purl.org/TEI/FR/3504690.

http://purl.org/TEI/bug/3439587 (Problems introduced by content models of 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.

Roma Templates and Example Customizations

The purpose of this discussion is to align Roma and the TEI customization web page, and clarify categorizations of customizations (e.g., What does experimental or restricted mean?)

Two things to do: fix the language on the TEI customization web page (http://www.tei-c.org/Guidelines/Customization/index.xml ), and decide what will be included in Roma as an available customization in the drop down list. In particular, is there a distinction to be made between things like Bare, Lite, and the MS or drama customizations?

Those who teach workshops using Roma like the pre-existing templates

MH: Roma should not appear to support things that TEI Council doesn’t support, because it leads people to think Roma is broken (i.e., community customizations should be clearly external)

Action on LB: In Roma, split the existing create customization from template button into two options: create customization from template and create customization from community customization, which can be opened from a list in the wiki (http://www.tei-c.org/wiki/index.php/Category:Customization) or the TEI-C Website. also remove the label experimental from those items in the drop down menu that have it.

Spelling of customiz/sation needs to be made consistent. Action on MH: Normalize spelling of customization in Guidelines and Roma.

Action on KH: remove experimental and restricted language from TEI Customization page. Use instead: the following are not available as DTD or XSD.

Action on SR: give admin access to JC and MH to Oxygen TEI repository.

If we go forward with pointing from Roma to the wiki page, Council should contact the owners of customizations and ask if they want to update/add to the customization.

Div.Liminal (LB)

LB proposes that we create a web app for letting people do sample encodings, gather examples via competition/community engagement.

Discussion of whether to offer pre-determined multiple choice options (more work upfront to create examples) or seek open ended answers (more work after to collate).

PS volunteers to collate results.

KH: make clear that people may interpret the guidelines as written, or propose an ideal/rational encoding not currently not currently allowed by the Guidelines.

MH: Exide might be a useful tool to use (http://exist-db.org/exist/eXide/index.html.

Action on MH: provide tech support to existing div.liminal working group (LB, KH, PS) regarding setup of eXist and eXide.

Action on LB / PS / KH: Div.Liminal Working group will report back to council with rational proposals of how to deal with tops and bottoms of divs.

LingSIG issues (PB)

PB is introducing a LingSig experimental space on SourceForge. Wonders if TEI will be moving to GitHub.

Discussion of pros and cons of moving part of TEI repository on GitHub; conclusion that in any case P5 will be on SourceForge for forseeable future until clear benefits make a move inevitable.

Action on PB: http://purl.org/TEI/FR/3561933 is already assigned to PB.

In answers to questions from PB, EP noted various details about the TEI Conference.

Ticket Processing

http://purl.org/TEI/Bug/3555602 (Odd by example). Is it the Council’s place to maintain this, or should it be on the wiki?

oddbyexample.xsl is a stylesheet by SR that takes in lots of TEI that you feed in, and makes its best guess at generating an ODD from your encoding

It produces the older version of ODD: inclusion rather than exclusion.

Council agrees that the concept is great, but there is concern about feature request creep.

Discussion about whether Council should support freestanding TEI tools in the core repository (this would be a new category of stylesheets, etc. to support).

MH: two different questions: 1) just let oddbyexample sit in the repository? 2) Should Council actively seek to maintain freestanding tools?

KH updated wiki to document oddbyexample

Action on MH: proof and expand wiki documentation for oddbyexample by KH http://wiki.tei-c.org/index.php/Oddbyexample.

Action on SR: review the tools, add ons, and other code currently in the TEI repository that perhaps should be removed (because they are not core to the functioning of the Guidelines).

Wider problem: we need clear, obvious explanation of tools, add on, stylesheets, etc. because most users don’t know they exist/are available. Action on LB / KH: to find the text SR drafted, edit it, and tell KH where to put it on the website.

Council agrees that for now, oddbyexample should be a separate add-on tool documented in the wiki, while a future Roma should consider supporting the functionality of generating an odd from your provided encoded texts.

http://purl.org/TEI/Bug/3376456 (deprecate use of gram except as a child of gramGrp). Waiting on KH and LB to formulate deprecation procedure, as assigned yesterday. Action on LB: When deprecation procedure is formulated, deprecate use of gram except as a child of gramGrp per http://purl.org/TEI/Bug/3376456.

http://purl.org/TEI/FR/3555191 (New element < citedRange > for bibliography).

Discussion of possible ways of citing a range cited, as opposed to the range of an entire work: biblScope, ref, or the proposed citedRange

MH: if many examples of citedRange also include a bibleScope, this will help clarify the difference for users.

Action on KH: create citedRange, allowing target to point out to a source. The full description of the cited range (e.g., volume, page, column, line) should simply be plain text inside citedRange. The content model of citedRange will be macro.phraseSeq. Change the gloss of biblScope from (scope of citation) to (scope of reference); Returning to Council as needed for implementation advice (see http://purl.org/TEI/FR/3555191). In addition, implement new ticket (http://purl.org/tei/fr/3570037): add unit to biblScope and deprecate the use of type.

Board Proposals for Council Consideration (EP)

EP reports on shrinking budget, institutional membership issues. Board is assessing options for reducing costs, sustaining income, incentivizing membership. Council is invited to contribute proposals, ideas and suggestions, either as individuals or as a body.

Some ideas resulting:

Should one of the TEI Council Meetings be before DH Conference? (General consensus seems to be it might be a good idea, though almost no existing council members would directly benefit.)

Should the size of board and/or council, and/or the number of people who attend each f2f meeting, be reduced? (Council agrees that even with a lower budget, we would want to keep the same number of members.)

Should council have a limited amount of subsidy per meeting and more remotely-participating members?

What is a sustainable/reasonable level of membership in the TEI consortium, both in terms of cost, and size/influence of the member (a person, an organization)?

Translations: Discussed difficulties of keeping I18N of element descriptions up to date. LB mentioned translation memory systems, for example OmegaT http://www.omegat.org/en/omegat.html.

Translation of the guidelines, website is one way to seek buy-in from European communities.

Institutional membership has only been considered from the POV of the North American university business model. In Europe, Asia, etc., institutional contribution to initiatives like TEI-C are managed differently.

Documentation on writing ODDs

We have very similar information on writing ODDs in the Guidelines and on the TEI-C website. These should be merged into one place. Where should the merged documentation be? Can someone review each document to make sure it’s accurate before we ask someone to merge the two?

Action on MH: review the ODD tutorial on the website and update it as needed. New ticket created for this: http://purl.org/tei/bug/3570106.

Action on KH: after Martin has finished updating the tutorial, synchronize the tutorial and the Guidelines by adding any essential bits from the tutorial to the guidelines (without turning the prose of the Guidelines into a tutorial), and checking for consistency between Guidelines and tutorial.

Questions for candidates (See David Sewell’s Email http://lists.village.virginia.edu/pipermail/tei-council/2012/016259.html)

Council would rather see a more detailed prompt for the candidate statement than a list of questions to be answered.

Council members who have further thoughts can send them directly to the nominations committee, or to JC.

Action on JC: Council will discuss on list the precise wording of the prompt for the candidate statement; JC to initiate, and report back to nominations committee.

Ticket Breakout Groups

Group A

http://purl.org/TEI/FR/3565878 (idno inside biblStruct)

LB has corrected the example in the Guidelines that illustrated idno as a child of biblStruct, moving the idno within monogr

Action on LB: Add some prose to this chapter of the guidelines to put the idno within monogr, and/or analytic, and/or series (as it applies).

Council agrees to deprecateidno as a child of biblStruct. We should not make the change now because TEI has modeled this (in example and its own practice) for too long.

Action on LB: fix the TEI Guidelines bibliography so that its idnos are inside monogr; see ticket http://purl.org/TEI/FR/3565878.

http://purl.org/TEI/bug/3547289 (model.gramPart and cit)

Action on KH: to carry out the work set out by KH and Laurent on the ticket (http://purl.org/TEI/bug/3547289). This comprises:

• Create a new model class (model.structuredEntryPart) which contains as members all of the current members of model.entryPart except for the grammatical features that can occur inside of gramGrp (model.morphLike).
• Change model.entryPart so that it includes as members model.structuredEntryPart and model.morphLike.
• Change cit and nym to use model.structuredEntryPart instead of model.entryPart.

This will break backwards compatibility and it would also require changing examples that will be rendered invalid. We agreed to do these things neverthelesss.

Group B

http://purl.org/TEI/FR/3561933 (Encoding of Standoff annotations).

Council agrees with Group B who thinks that this will be a beneficial addition to the TEI and that an we should have a container element standOff as part of model.resouceLike which contains things like linkGrp/link, seg/ab/s/etc. and various other elements, including some new elements to be discussed by a later working party.

Action on LB / PB / MH / RW / JC: A working group including LB, PB, MH, RW, JC will come back with a formal proposal for a standoff markup container element. See http://purl.org/TEI/FR/3561933.

http://purl.org/TEI/BUGS/3532022 (lg should be allowed in p).

Group B agrees with this one and thinks it should be added to model.inter, resolving any resulting ambiguous content models. After significant discussion Council accepted this decision.

Action on MH: implement http://purl.org/TEI/BUGS/3532022.

http://purl.org/TEI/BUGS/3519806 (name should be a member of att.datable).

Group B agrees with this one as well, name should claim membership of att.datable. Further rationalization of these should be examined.

Council agrees that name should be a member of att.datable; it should probably also be a member of att.personal but this should be considered further by the implementor.

Action on JC: implement http://purl.org/TEI/BUGS/3519806.

Group C

http://purl.org/TEI/FR/3523791 (an addition to timeline to record stretches of time).

EP proposes that Council revisit the way temporal linking is handled as a whole.

LB expects that this will be addressed to some degree in the Berlin multimedia meeting in October, from which he will report back.

Council agrees to close this ticket categorized as rejected. The Guidelines already supports a way to do what SR is asking for, but agree that temporal linking should be re-examined as a whole at some point in the future.

http://purl.org/TEI/FR/3518932 (Use range instead of abusing from on span)

Action on GB: to submit a ticket requesting clarification in the prose of the Guidelines on the use of from on other elements such as locus and biblScope. Close the originating ticket http://purl.org/TEI/FR/3518932 as it stands as won’t fix.

http://purl.org/TEI/FR/3523225 (New attribute keepHyphen)

Council agrees not to fix this ticket because a better solution exists, involving glyph and g as suggested by LB on the ticket.

Action on EP: to find an example to incorporate into the Guidelines demonstrating LB’s encoding solution for the issue raised in http://purl.org/TEI/FR/3523225.

Action on LB: Add clarification of the issues raised in http://purl.org/TEI/FR/3523225 to the Guidelines (3.2.2) CO.html#COPU-2 existing discussion of hyphenation.

Action on LB: to correct the definition of g in the Guidelines: represents a glyph, or a non-standard character following issues raised in http://purl.org/TEI/FR/3523225.

Action on LB: to close http://purl.org/TEI/FR/3523225 with explanation.

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:

The two main candidates for code bounties are the Roma front-end and a second ODD processor. After some discussion, we came to the conclusion that in the case of an ODD processor, we would be open to the use of any language/platform, but in the case of the Roma ODD-editing interface, we would probably want to specify in advance a list of tools/languages we would feel comfortable with taking on, since Roma will be owned and operated by the TEI in the long term.

Other possibilities are: tools for working with ODDs, such as an ODD-diffing tool, or ODD visualization tools. Council agrees with JC that it would be a good thing if a new Roma were written somewhere other than Oxford, and preferably in the larger community rather than just by existing Council members. The exact specification for a new ODD processor would be very difficult to write, in that there are lots of aspects of ODD output which are currently undetermined. We could put out a general code bounty with a list of things we are interested in, and choose among the proposals we receive. KH: we have consensus that a new Roma is the sort of thing we know we need, and which needs to be in place before the TEI starts to rebrand and re-advertise itself. JC: it seems to be our view that the majority of a code bounty should go towards a rewrite of the Roma interface. Should it be owned by us, or should it be in its own repo in SF or GitHub? The consensus is that TEI-C should own a Roma rewrite. RW: it would be desirable for a new Roma to be open-ended in such a way that subsequently-developed ODD-processing tools could be plugged into it via some plug-in API.

Action on JC and LB: Resolved: JC and LB will produce a draft of a code bounty for a loose specification for a Roma rewrite, which will come back to Council for comments. This will include a list of preferred languages/tools, the need for a plugin API etc. Council aims to release a public call in about two to three months, with the idea that work will begin early in 2013.

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:

• It is archived in the Vault and the link points permanently to that location, and Lite is never changed;
• Every new release would include a new build of Lite, but we would not make any changes at all;
• Or, we continue to maintain Lite (in the sense of fixing anything that gets broken, but not in the sense of adding anything new to 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

.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.

Ticket Breakout Groups

http://purl.org/TEI/FR/3556778 (retaining punctuation marks in the text of a TEI document). PB, BB and RW: There are four parts to this ticket, including issues with whether you should retain punctuation such as quote marks within an encoding, and if so, whether they should be inside or outside an element. Some members are reluctant to make clear recommendations one way or the other, but we should recommend that people document their practice, whatever it is. Chapter 3.2.1 doesn’t mention that you might use the quotation element in the header to explain your encoding practice, and it should. The implication of the Guidelines text is that you should include them, and this should be made explicit. A new attribute might be created which would enable you to specify whether quotation marks are inside or outside the element. This might apply to other punctuation marks, such as brackets around stage directions. MH: there are already ways to do this, including the use of rendition/rendition. BB: that’s not the same thing at all; this starts from the assumption that you have captured the punctuation marks, and you want to document where you put them. LB: The element quotation is too specific, perhaps, and should be punctuation. RW agrees. One proposal would be to introduce a new element punctuation in encodingDesc, and deprecate 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.

http://purl.org/TEI/BUGS/3515805 (confusing semantics of ns). MH, SR & LB: There was a discussion in January about whether ns means the input namespace or the target output namespace for the thing being created/described. The mode attribute indicates whether or not you’re intending to change this or just import it. On looking at the specific example concerned, it turns out there is no situation in which you need ns to specify the input; instead, you can do this by specifying a namespace prefix on the ident. Action on SR: Test Roma to see what it does with a namespace prefix on ident; clarify the examples in Chapter 23; create an attribute class to hold ns (instead of defining it separately on elementSpec and friends).

http://purl.org/TEI/FR/3548625 (Extend the enumerated values for list/type). KH, GB & PS: The values given for list/type are a strange mix of presentational and semantic. However, making a change to this would be massively disruptive to existing documents, so a change is not recommended, but the Guidelines should be expanded to show more examples. Ideas for completely redesigning list should be added to the P6 Dev page. To answer the ticket itself, we should add examples which use 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.

Experimental modules, lists of customizations, etc.

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

SR should explain the purpose of providing downloadable customizations.

On http://www.tei-c.org/Guidelines/Customization/ and http://www.tei-c.org/Guidelines/Customization/odds.xml, are any modules labeled as experimental that should not be, or any modules not labeled but should be? (Note that currently the dictionaries module is documented differently on these two pages.) SR said that none are experimental any more.

Roma interface, supported customizations and documentation

Do we agree with SR removing MS, dict, speech, drama, and corpus from the Create Customization from template drop-down menu at http://www.tei-c.org/Roma/? SR noted that Bare, Lite, and Tite make sense since they are coherent and have a purpose, and that SVG, MathML, XInclude, ITS, and ODD are also sensible since they involve non-obvious techniques which you can’t recreate easily in Roma. But the remaining five are are not meaningfully useful or documented, nor do they follow any known recommendation. JC said they were supplied here as simple example customisations. MH suggested separating out such options as “advanced”.

Should we provide templates for community-created customisations in Roma that are reasonably mature and well-supported, such as EpiDoc? What would be our management process for this?

Should we begin generating HTML and PDF documentation for any modules besides Lite and Tite (and putting them in http://www.tei-c.org/release/doc/tei-p5-exemplars/)?

For the two sections of customizations at http://www.tei-c.org/Guidelines/Customization/:

Do we want to rename the first heading Customizations provided by the TEI Consortium to Customizations maintained by the TEI Consortium or Customizations supported by the TEI Consortium?

Can we clarify what more restricted or experimental means? These are not the same thing, and it isn’t clear what either means.

Do we want to set up a procedure for deciding what can be added to the TEI Community Customizations or for periodically revisiting those listed there? Even if not, should we just go ahead and remove MEP from the list since the links are broken and it’s a P3 thing?

Do we find the heading TEI Community Customizations clear enough, or do we want to add a paragraph here explaining it?

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

http://purl.org/TEI/FR/3519866 (rend from data.word to text). LB apologises profoundly for the typo on his ticket comment. The three options under consideration are:

• Status Quo: rend stays the same (multiple non-sequential, space-separated tokens similar to html’s class attribute), clarified in Guidelines.
• Allow space in rend (as per ticket request) and clarify Guidelines.
• Space is only for multiple non-sequential tokens in rend but create new style attribute with a documented Formally Defined Language for it (and create styleDesc element or similar solution for documenting the style language used).

JC argued for #1, but in the end Council voted in favour of #3. Council then discussed at length the extra suggestion by LB that rendition and rendition be renamed to styleDesc and styleRef, to minimize confusion. Council voted 5 to 4, with one abstention, in favour of this. Since this was indecisive, and would have such backwards compatibility issues, this question should be spun off into a separate ticket and discussed over the next few months. Action on LB: implement the style attribute per http://purl.org/TEI/FR/3519866.

style will be created as string (data.text) in att.global.

It will be defined as containing a formal style language.

All three attributes (rend, rendition, style) can be used in combination.

A new element, which will be declarable, to specify the style language will also be created after discussion on council list.

scheme on rendition should be moved into its own class, so that the new element can have it.

Action on JC: rend references throughout Guidelines will be clarified to note it is a sequence-indeterminate bag of space-separated tokens.

http://purl.org/TEI/FR/3521288 (Dead Link for http://www.ons.gov.uk/about-statistics/classif). The original ticket morphed into a discussion of the use of scheme and code; since the latter normally points to a subsection of the former, there is no need for both. Action on MH: The original issue of the broken link in http://purl.org/TEI/FR/3521288 must be fixed. (assigned to MH). Action on JC and LB: The scheme attribute should be redefined so that it need not point to a taxonomy element; it can point to an external scheme. Similarly, 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.

http://purl.org/TEI/FR/3522043 (Version numbers link to page about versions?) KH: The page we could link to at that point tells you about versions, but does not explain the numbering of versions; that information (including a link back to the Guidelines — the P5 page mentioned in KH’s last comment) should be included on the page to be linked to. Action on MH: Implement linking of the “Version 2.1.0” at the bottom of each HTML page to something, possibly to http://www.tei-c.org/Guidelines/P5/#previous, or better, to something which explains what version numbers mean and then links on to the above location.

http://purl.org/TEI/FR/3416130 (Allow certainty etc. inside milestoneLike elements). GB and LB have stated their positions on the ticket, and GB has previously reported to the Council list on this. The main objection is that hitherto empty elements would now have content. LB: A compromise would be the introduction of a new class model.metaMark, along with revision of the content models for the proposed elements from (EMPTY) to (model.metaMark*). SR: this fails because certainty has model.glossLike in its content model, so being able to put certainty in gap will bring the possibility of textual content in a desc. This makes many people uneasy because existing processors may suddenly start displaying text from the desc where nothing was displayed before. Following an inconclusive vote, this ticket was deferred pending further discussion on council list. Action on ALL Council: Discuss http://purl.org/TEI/FR/3416130 further.

http://purl.org/TEI/FR/3064757 (XML construct encoding within Schematron). Council voted to reject the ticket, but undertake to look at consistency of encoding in the existing Schematron rules. Action on SR: reject and close http://purl.org/TEI/FR/3064757, but examine consistency of encoding in all current Schematron rules.

http://purl.org/TEI/FR/3475007 (New section on encoding text directionality) Action on MH: consult such people as D. Anderson, F. Sasaki and M. Bingenheimer, along with the TEI-L list, to put together a group to create a recommendation for a new Guidelines section on encoding text directionality.

http://purl.org/TEI/Bug/3480650 (cRef is a mess).LB and SR: Suggestion on ticket accepted. cRef will be moved into a class, and given the datatype data.text (it must be so since canonical references can contain spaces). The bulk of the discussion on the ticket is tangential. The last part of the original suggestion is not right, though; data.pointer is wrong for cRef because of the spaces. Action on LB: move cRef into a class, and give it the datatype data.text per http://purl.org/TEI/Bug/3480650.

http://purl.org/TEI/Bug/3413346 (Deprecation of data.key and data.word attributes). GB & JC: The main conclusion was that most of the ticket needs more discussion, so the ticket should remain open. Some of the proposals in the ticket (e.g. that a handful of attributes such as lemma etc. would be better served by a pointer of some kind) are wrong, however. Reassigned back to MH, who proposed it, to close this ticket and open a cleaner one on the topic of deprecation of data.key. Action on MH: close http://purl.org/TEI/Bug/3413346 and open a cleaner ticket on the topic of deprecation of data.key.

http://purl.org/TEI/FR/3547558 (*Spec elements could have keywords or use ana). BB & MH: We suggest that you could just create classSpecs for this purpose, instead of using another mechanism.The classSpec might have only this purpose. This would require the additionof an extra value for classSpec/type, something like 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.

http://purl.org/TEI/FR/3561938 (New tag element for grouping elements). PS & RW: As described, the ticket is very broad, and would require a meta-element of which all the existing elements would be children. As stated, it’s far too large and vague; the use-cases are all met by existing mechanisms; and the stated reasons such as improved processing speed are red herrings. Ticket to be rejected and closed. Assigned to MH. Action on MH: Reject and close http://purl.org/TEI/FR/3561938 with an explanation.

http://purl.org/TEI/BUGS/3523082 (XPointer schemes may not nest, but see ch. 16). Action on GB: incorporate http://purl.org/TEI/BUGS/3523082 into the SOM group discussion of TEI Pointers.

Final discussion on release date and plan: PB will be the release technician. Release day will be determined by PB’s schedule, and all source changes must be submitted three days before release day. Following that, all Council members must proof and check for errors and inconsistencies. Action on JC: Organize Council work for next release.

Council discussed the scheduling of meetings, specifically whether we should piggy-back on e.g. the DH conference instead of having separate meetings. The consensus was that there currently is no significant advantage to trying to do this, since there is no conference where more than a few members are likely to go.

JC thanked all Council members for their time and commitment and reminded them to attend to tickets and actions assigned to them.