Paris 2011-11 minutes

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:

FRs:

1. 33415411: Split certainty/precision/respons from model.glossLike. Straightforward ticket: LB will do it and close ticket.
2. 33411906: Ticket was already implemented by LR. Ticket now closed.
3. 33408683: hyphenation section doesn't reference pc@force. Decided, and MH has already proposed wording. MH will implement and close ticket.
4. 33296398: 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. 33293070: enhancement of notes and examples in ref-del. EP disagrees with KH's comment; she maintains that there is a difference between <gap reason="deleted"> and <gap reason="cancelled">. So "deleted" needs to be added to the list as well. GB will be asked to implement the proposed changes.
6. 33282689: 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. 33275613: make textLang usable in bibliographies. Proposal now is to move <textLang> 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. 33266021: 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 <sense>), so as not to absolutely de-legitimate it.
9. 33210946: examples for digital facsimile. We will defer this until we talk about the genetic module.
10. 33064014: 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. 33051750: 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. 33046288: allow f to contain pcdata. LR will implement this, getting examples from documents created by the group requesting the change.
13. 33041605: 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 <listPerson>; a template <person> can be sent out to TEI-L. LB reminds us about privacy concerns.

BUGS:

1. 3343221: i18n revision due. Deferred in favour of a broader discussion of translations.
2. 33400295: Inconsistent definitions for some elements. MH will provide LB with examples of <label> used to mark topic transition in prose text.
3. 33304622: 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. 33289073: many missing references in guidelines. SY will implement; KH will handle the three references he added.
5. 33285020: irregularities in <gram> syntatic 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. 33223544: 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. 33423687: a general purpose <description> alongside traits/states. LR, PB: The proposal for a new <description> element is rejected. However, there is still an issue to deal with. <trait> and <state> 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 <trait> 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 <state> in favour of <trait>; or use the Guidelines text to explain that if you're confused about the difference, use <trait>, and that <state> is syntactic sugar for <trait type="state">? We recommend that <trait> is the default element to represent semantics of properties etc.; this will require an adjustment to the definition of <trait> to make it broader, so that it can be used for temporally-bounded characteristics. After some discussion, we decided that <state> makes a more obvious default, because it can handle both temporal and non-temporal properties. So: in immediate response, we will suggest <state> as the default choice, purify the <trait> examples in the Guidelines to remove the temporal attributes, check all the <trait> examples to see which need to be changed to <state>, and raise a new ticket to consider the merging of model.traitLike into model.stateLike. During this discussion, LB admitted to disagreeing with PB by pure reflex, with no justification whatsoever. He later agreed with him without justification as well, to redress the balance.
2. 33412198: JC, MH: make listPerson and listOrg member of model.personLike. We should add <listPerson>, <listPlace> and <listOrg> to <org>; and add <listOrg> to <particDesc>. LB suggested creating a new model.orgPart, which would make the changes to <org> simpler, and adding <listOrg> to the content model of <particDesc>. LB will implement it.
3. 33408897: KH, EP: @role for <publisher>. To deal with this ticket, we should allow <respStmt> within <imprint>. We would then have ways to handle more than just publisher-like roles within <imprint>. This requires broadening the definition of <resp> and <respStmt> 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. 33311604: 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. 33086675: Expand note on <availability>. Assigned to MH to finish implementation.
6. 33113682: make ptr & ref member of att.internetMedia. Assigned to MH to finish implementation.
7. 32834511: 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 (<addSpan> and <delSpan>), 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. 32925145: 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. 33060867: Grouping traitlike, statelike, and eventlike elements. LB, PB: We should create a new <listState> element, to be added to the content models of <person>, <place> and <org>, 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. 33393244: simplify content model of <subst> 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 <subst> (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 <substJoin> 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.

== ROUGH UNREDACTED VERSION OF DAY 2 MINUTES ==