Council Tracker Review: 3 April 08

Posted first draft to website

This document summarizes outcomes from the TEI Council’s review of outstanding tracker items (source forge feature requests and bug reports) as discussed and agreed at its meeting in Galway, 3-4 April 2008. In some cases, Council’s recommendations were suffiently complete and clear for the ticket to be closed after some minor modifications to the P5 sources; in such cases, the changes have been made and in the brief description below the phrase “[closed]” added. In other cases, some additional examples or other work is required before the ticket can be closed; where a specific Council member was actioned to carry this out, this is noted below.

    This ticket combines several issues, some of which have subsequently been resolved or superceded. Please resubmit a new ticket explaining the need for a clarification element, though, as this has not so far been addressed. [closed]

    Council agrees that a new @precision attribute with possible values high, medium,low should be added to att.dimensions class. However, there is no such attribute on date at present: it should probably be added to att.editLike. In more complicated cases, a new precision element will be needed: this should be put forward as a new proposal.

    After much discussion, Council agrees that @facs is a more specialised version of @corresp, which associates an image (or a part of one) with an element containing some alternative representation of the image, typically but not necessarily a transcription of it. The class spec has been revised accordingly: the chapter may also need attention.

    Council recommends that deletion within a substitution should always and only be marked using the del element, for consistency of treatment. Where the material deleted is illegible, a gap may be used within the del. The suggestion of using gap reason=deleted in the Guidelines has been removed. [closed]

    This has been implemented: since the values of the type attribute are to be constrained, the attribute must be locally defined. [closed]

    A note on the spec for lbl explains that it is a generalisation of usg; and there are nine examples of its use throughout the chapter. I’ve added a sentence to the first place it appears referencing the following section which contains several examples. [closed]

    Council discussed but deferred action pending further work, e.g. to provide more examples (PB agreed to take ownership of this issue).

    Council agrees that such lists might be helpful; the stylesheets used to generate the documentation will be modified to produce them accordingly (SR).

    Council agrees that @facs is preferable, while noting that this introduces another module dependency. Prose of chapter and spec have been revised to clarify how @target should be used. [closed]

    Council reviewed this document, but did not feel that its contents were appropriate as a chapter of the Guidelines. It was felt that many of the topics adressed would be usefully provided as a standalone tutorial guide of some sort. SR and DPOD agreed to look into specific usecases and related stylesheet issues. PB would include discussion of the topics raised in his introductory guide.

    Council agrees, noting however that the description of the desc element needs generalizing. A desc child of interpGrp is also needed. Specifications for interpinterpGrp model.glossLike and desc have been modified accordingly.[closed]

    Council agrees that this is a useful addition, but feels that q should be available as well as quote and therefore recommends adding model.qLike instead. (This also makes cit and said available, which seems a little odd.) [closed]

    Some prose added to CO; example to be provided by david shortly

    Council noted that the use of the @lemma attribute to hold textual data was inconsistent, but also recognised that this was a very common usage. The simplest solution appeared to be to change the datatype so as to permit spaces. Council also proposed adding a new @lemmaRef attribute to point to a definition of the lemma held elsewhere. This would provide a pair analogous to the @key @ref attributes on name etc. The child element solution would also require definition of some other child element to hold the non-lemmatised form. Changing @maxOccurs would introduce ambiguity. Some more prose is needed to introduce the new attribute within #AISP. [pending]

    Council agreed to add this element to the att.typed class. In discussion it was noted that specific examples of the proposed use of the @scheme attribute was necessary: GB to investigate.

    Council agreed that @quantity might be a better name, if only for reasons of consistency, but did not formulate other detailed specific proposals: JC and GB to investigate further.

    Council agreed that this needed an example.

    Council’s opinion was that the @form attribute was not useful, and should be deprecated, and removed at a later release. The element spec has been updated accordingly; in particular, the closed value list has been removed. [closed]

    This change has been made. In addition, Council proposed that graphic and availability shd be declarable. [closed]

    Council noted there was still need for an example: AC to provide one

    Council agreed that using div would be appropriate in some but not all cases, e.g. where postscripts “floated” within the body of a letter. The problem should be addressed by the proposed new activity on epistolary matters.

    Agreed. The same element should also be provided on analytic, series

    Att name to att.typed is OK but can it be restricted? allow both.

    The recommendation accepted: make it a member of att.dimensions, retain extent: it’s deprecated in favour of quantity

    The fact that this and possibly other elements needs @nymRef, but not the other members of the att.naming class suggests that a class reorganization is needed. The proposal is to make a new class, att.canonical, containing just @key and @ref.

    Council agrees that @key and @ref should be provided on title. As well as usage examples, some discussion of when these attributes are appropriately used is needed.