Paris 2011-11 minutes

Official version at http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml

November 7 2011
Present: Laurent Romary  (LR) Brett Barney    (BB) Lou Burnard     (LB) Elena Pierazzo  (EP) Kevin Hawkins   (KH) Piotr Bański    (PB) James Cummings  (JC) Martin Holmes   (MH) Remote: Stuart Yeates   (SY) Sebastian Rahtz (SR) Gabriel Bodard  (GB)

LB will record details of decisions on SF tickets, and occasionally implement changes where they're straightforward.

MORNING: GREEN TICKETS
Review of Green bugs and FRs discussed previously by email:

FEATURE REQUESTS

 * 1) 3415411: Split certainty/precision/respons from model.glossLike. Straightforward ticket: LB will do it and close ticket.
 * 2) 3411906: Ticket was already implemented by LR. Ticket now closed.
 * 3) 3408683: hyphenation section doesn't reference pc@force. Decided, and MH has already proposed wording. MH will implement and close ticket.
 * 4) 3296398: add hi to figDesc. Looks trivial, but actually quite complicated. SR's comments make sense. LB volunteers to test whether SR's proposal works.
 * 5) 3293070: enhancement of notes and examples in ref-del. EP disagrees with KH's comment; she maintains that there is a difference between and . So "deleted" needs to be added to the list as well. GB will be asked to implement the proposed changes.
 * 6) 3282689: replace 'file' with 'document'. Even SY agrees that it might not be worth it to implement the ticket; anyone can replace individual usage where they come across it. The ticket will be closed.
 * 7) 3275613: make textLang usable in bibliographies. Proposal now is to move  to core, and move all the corresponding discussion of the element. LB objects a bit because core is too big, but that's a different issue. JC will actually implement it.
 * 8) 3266021: dictionary entries with a single sense. LR says this is a consistent repeated request from users. LB is unconvinced; PB thinks that much broader changes must be undertaken in the dictionaries module in the future, and is uneasy with this because of his practice of building up markup progressively. Nevertheless, it will be implemented; KH will do it, and will leave in one example of the practice we now deprecate (not using ), so as not to absolutely de-legitimate it.
 * 9) 3210946: examples for digital facsimile. We will defer this until we talk about the genetic module.
 * 10) 3064014: provide suggested values for rs@type. Over objections by SR and LB, the Council agree that it's a good idea in any discussion of @type-like attributes to provide a pointer to an existing ontology or taxonomy. We have a current practice in which syntactic sugar @type values are taken from the names of the corresponding elements; we should express this clearly under @type's explanation. There should also be a comment on the general definition of @type to the effect that we recommend the use of existing taxonomies where suitable.  We should also ensure that all our examples in the Guidelines are consistent with this practice, so one example in 3.5.1 needs to be changed ("organization" -> "org"). However, rs defines its own @type, so the same text needs to be added there. The reference to the BBN taxonomy belongs in rs/@type, not the general @type. KH will implement this.
 * 11) 3051750: choice of schema language when using the TEI. The only comments are against the ticket, and KH was initially OK with closing it unimplemented, but the general sense of the Council is that there should be some information about the various advantages and disadvantages of particular schema types. He believes this belongs in 23.3.2. LB points out that there is a basic discussion in the General Introduction. LB suggested a rewording of the second para or 23.3.2, moving the first sentence after the second, and modifying it somewhat. A broader discussion belongs elsewhere, either a wiki page or Roma. The consensus is that it belongs in Roma, on the Generate Schemas page; SY suggests it should take the form of a link to a Wikipedia page. JC will write the sentence, and insert it into Roma.
 * 12) 3046288: allow f to contain pcdata. LR will implement this, getting examples from documents created by the group requesting the change.
 * 13) 3041605: update list of Council members. The Council agrees that the current list of members should be updated, and that a complete list of current and former Council members should be maintained and included in the Guidelines. KH will collect info from LB and elsewhere to create the list, and MH will then take over to create a more robust and formal collection of info based on a ; a template can be sent out to TEI-L. LB reminds us about privacy concerns.

BUGS

 * 1) 3432216: i18n revision due. Deferred in favour of a broader discussion of translations.
 * 2) 3400295: Inconsistent definitions for some elements. MH will provide LB with examples of used to mark topic transition in prose text.
 * 3) 3304622: invalid xml:lang= values. EP and PB: We must use two-letter codes where they exist, and where they don't, three-letter codes can be used; locations should be in upper-case. PB will recheck Syd's list and fix all bad examples.
 * 4) 3289073: many missing references in guidelines. SY will implement; KH will handle the three references he added.
 * 5) 3285020: irregularities in syntactic sugar variants. LR suggests that we create a new attribute class for dcr:datcat, apply it to all the model.gramPart elements, and then wait for other requests for the same attribute. PB will implement this, and make a list of other elements that might also want it (in collaboration with the linguistic sig).
 * 6) 3223544: use of head and p within figure. Solution: remove "Figure 1: " from the second example, to reduce confusion. LB has implemented and closed the ticket.

General discussion
LR commented that he would like to see many people in the community implement tickets in future, based on OK from Council.

Who should assign colours to tickets? At the moment it's LB who assigns colours, but others could/should. The submitter shouldn't, but the first commenter perfectly well could. For clarification:

GREEN: It's clear what needs to be done, or is being requested. AMBER: It's not yet clear what action is requested. RED:  It's completely unclear what's being requested or suggested.

AFTERNOON: AMBER TICKETS

 * 1) 3423687: a general purpose alongside traits/states. LR, PB: The proposal for a new element is rejected. However, there is still an issue to deal with. and are essentially the same, the only difference being ontological (essential vs incidental). The content model is the same, and they are both timed. In the long run, we would want to keep only, and when you need to differentiate essential and incidental, you rely on the @type attribute, and the possible temporal attributes you may use to limit applicability. Should we deprecate in favour of ; or use the Guidelines text to explain that if you're confused about the difference, use, and that is syntactic sugar for ? We recommend that is the default element to represent semantics of properties etc.; this will require an adjustment to the definition of to make it broader, so that it can be used for temporally-bounded characteristics. After some discussion, we decided that makes a more obvious default, because it can handle both temporal and non-temporal properties. So: in immediate response, we will suggest as the default choice, purify the examples in the Guidelines to remove the temporal attributes, check all the examples to see which need to be changed to , and raise a new ticket to consider the merging of model.traitLike into model.stateLike.
 * 2) 3412198: JC, MH: make listPerson and listOrg member of model.personLike. We should add ,  and  to ; and add  to . LB suggested creating a new model.orgPart, which would make the changes to simpler, and adding  to the content model of . LB will implement it.
 * 3) 3408897: KH, EP: @role for . To deal with this ticket, we should allow  within . We would then have ways to handle more than just publisher-like roles within . This requires broadening the definition of and  to allow them to apply to organizations. We should also consult with the workgroup who looked at physical bibliography for more guidance on requirements in this area. LB objected that there was little distinction in the past between the functions we now distinguish (printer, bookseller etc.>); EP objected that this is certainly not the case for early printed books, and gave examples. The Council decided that KH & EP's solution should be implemented, and MH will implement it.
 * 4) 3311604: att.coordinated language. BB, LB: Point 2 is agreed: we need more examples of @start. Point 1: should be rejected because we can think of good use-cases where both may be required; Point 3: We can't really make much sense of the comment, except that we do need more examples of the use of @points. MH will look for (or create) more examples of @start and @points.
 * 5) 3086675: Expand note on . Assigned to MH to finish implementation.
 * 6) 3113682: make ptr & ref member of att.internetMedia. Assigned to MH to finish implementation.
 * 7) 2834511: Add more elements to att.spanning with schematron constraint. LR, JC: This introduces a parallel method of doing spanning for elements (add, del) which already have a method ( and ), so it's unlikely that anyone would have a need for it right now, unless we implement it for all of model.pPart.transcriptional. Everyone likes the longer-term vision of implementing spanning through att.spanning being added to many elements, but is unwilling to implement only a part of it that gives us nothing new. A working group of GB, BB and LB will go away and a) check which elements they believe should be included, and b) write an explanation of what it means when these spans cross element boundaries such as paragraphs.
 * 8) 2925145: Generic dating class. MH, KH: This ticket has a detailed implementation strategy, which was only waiting on the implementation of two other tickets before it could proceed; those have now been done, so it should be implemented. The new objection by ianrons is basically that up to now, people have been abusing @calendar because @datingMethod did not exist, so these two attributes may be confused; our response would be that now @datingMethod will be available, there is no need to abuse @calendar, and existing abuses can be fixed, or not, at the discretion of their perpetrators. Assigned to GB to implement.
 * 9) 3060867: Grouping traitlike, statelike, and eventlike elements. LB, PB: We should create a new  element, to be added to the content models of, and , and which would have a content model of model.stateLike (assuming that's the one we recommend in the other ticket). Assigned to PB for implementation.
 * 10) 3393244: simplify content model of to add and del only. EP, BB:  This ticket arose out of an old ticket which was previously discussed and assigned to JC, but was not implemented. The proposal is to deprecate the current model of (model.pPart.transcriptional); create a new content model that allows only add, del and milestone elements (starting with adding the milestones, removing model.pPart.transcriptional and replacing it with the individual elements, and then removing the others at the expiry of the deprecation period); and create  to allow the grouping of a range of elements. The Council gradually came round to the view that we should actually remove model.pPart.transcriptional elements now, and avoid the deprecation period, because the original inclusion of those elements was wrong, and therefore this is a bug and should be fixed. GB suggests we should actually use this as an exercise to work out how we should do deprecation. In the end we came down in favour of implementing it right now. GB will implement it.

GENETIC MODULE DISCUSSION:
[3210946: examples for digital facsimile. We will defer this until we talk about the genetic module.]

November 8 2011
Present: Laurent Romary  (LR) Brett Barney    (BB) Lou Burnard     (LB) Elena Pierazzo  (EP) Kevin Hawkins   (KH) Piotr Bański    (PB) James Cummings  (JC) Martin Holmes   (MH) Guest: Brian L. Pytlik Zillig (BZ)

Remote: Stuart Yeates   (SY) Sebastian Rahtz (SR) Gabriel Bodard  (GB)

GENETIC TRANSCRIPTION:
The transition between the discussion of and the explanation of


 * EP : We could try to use   to make element aliasing work, and then rationalize the names; we could push this problem forward to P6, and develop an explicit strategy for naming these things; or we could throw up our hands and do nothing. PB : We should fix  while we can. We should develop a clear set of naming principles for these things. LB : There is a general section in the Guidelines on naming of elements. A description should go there. LR : It should go in tagDocs because people use that when writing ODDs. LB : All but a handful of the <*Grp> elements are syntactically correct as groups; the exceptions are <transposeGrp>, which we've agreed to change, <forestGrp> , and <relationGrp> . LB will raise a ticket for this.


 * 1) Magic tokens ( JC, KH , LR ): The consensus is that we could integrate within @ref all the usages currently covered by @key , so the vision for the future is that we don't need @key . However, @key is widely used right now, so we should not remove it or deprecate it. We should modify the Guidelines to make the point that people should switch to @ref wherever @key is mentioned. KH will create a ticket and start implementing it.
 * 2) Translations ( MH, EP ): First, how should we realign the translations from 2007? Second, how do we put a system in place to ensure that translations don't get too far behind? Before we can act, though, we need to know whether the TEI prioritizes it or not, and is willing to put some money into it. To do that, we really need to do a survey of the community; such a survey would have to be multilingual, and we would need to make sure we can reach non-English-speaking users, so we'll have to issue a multilingual call, and ask TEI-L users to circulate it among their communities. PB : Adding requirements for translation of every change can actually make the maintainers of a project reluctant to make needed changes. We could also go for a wiktionary approach for element definitions, but that would be another environment to maintain. LR : First action is to issue a multilingual survey; second action is to implement models for translation environments and tools; thirdly, we need to find a way to officially validate or certify translations. We should report our intentions to the Board through EP , and we will raise a ticket that ensures we return to the issue at the next meeting.
 * 3) Architecture of TEI/ODD : LR, JC , LB : There are three main orientations that the TEI should follow in the medium- and long-term. First, we should make ODD feature-complete (getting rid of external vocabularies etc.). Second, we should start by working on the inheritance model to deal with the @type issue (enable the overriding of an attribute description inherited from a class). We should have a traditional class inheritance structure for e.g. content models. Finally, we should derive modules from this class inheritance.
 * 4) Tools : PB, KH , SR : The web Roma (not the command-line processor) needs a rewrite. Much of its functionality has been taken over by OxGarage. It can be done with JavaScript/AJAX. There are two ways to do this: get some money and pay an intern to do it, or apply for outside grant money. However, if we are going for outside money, we should have greater ambitions. Roma should be more generalizable, as LR wants, to use with non-TEI ODDs. The whole of the processing could actually be written in JavaScript and run on the client, so no server back-end is required. EP asked what about Vesta? SR notes that most of its functionality is available in OxGarage. Vesta was an experiment to see if we could write a desktop version of Roma, and it was never finished, and now can no longer be built. We no longer need it because we can do the same work in oXygen. Council concluded that we should look around for possible granting agencies that might give us a substantial grant for this, and earmark some time at the next meeting to polish a formal grant application. All council members should do this. We should also add OxGarage to the Tools page on the TEI site. KH will do that.
 * 5) Workflow for Community and Council : MH, EP , BB : First, the SF ticket system is only comfortable for programming types, so there should be an intermediate mechanism to enable people to submit a request to the Council mailing list, so one of us can pick it up and turn it into a ticket. This should be on the TEI website, and have a captcha. Second, the TEI by Example site is not linked from the TEI website; it should be prominent. This should be submitted as a FR. Third, our website is not helpful at all. It needs to be reimagined or restructured from the point of view of new users, in accordance with usability guidelines. For workflow with regard to Council, can we reduce the volume of messages and in particular the noise and trivialities. LB 's guide to editing the source needs to be expanded, and complemented by a semi-formal mentoring system to enable new members to become effective. We should also attempt to express formally the institutional knowledge we now share about e.g. tasks to be completed by the Council Chair and members prior to a ftf meeting. Actions: We will make public all the current expectations of members of Council prior to the next call for candidates. The Council page on the website should make this clear. JC will add EP as an admin on the TEI website so that she can make changes.

SIG report from the Linguistics SIG ( PB )
PB has sent to the Council a report on the TEI/linguistic bibliography list, created and maintained in the context of LingSIG. Action for JC : Before Council meetings, email the SIG lists to ask for reports or issues to discuss.

Priorities for the Next Year
We should have regular telcos every two months, and deal with tickets at all of them. Telcos should not be more than an hour.

The next ftf will take place mid-to-late April 2012. The date will be finalized before the end of the year.

The strategy for Roma is a priority (see above). We might be able to prod someone with the right skill-set to apply for a grant from the Board to do it; calls for applications will go out from the Board soon.

We should create a SIG for the ideas around the future of ODD, and invite likely experts and interested community members to join it.

Solve all outstanding problems regarding conversion from EEBO/ECCO.

Investigate methods of allowing element and attribute name aliasing, so that we could rename elements without breaking backward compatibility.