TEI taskforce on manuscript description [Notes presented to TEI Council meeting on 1 Jul 2004] Major changes (post-Gent): 1. The content model for now comprises: a required element, followed by an optional , followed either by one or more paragraphs or the specialised elements , , , and , all of which are optional, plus , which is optional and repeatable (we have, on further reflection, decided it would probably be better not to re-arrange the order of the elements, placing before , although we may want to review this). Expressed in good old DTD language this is: This content model allows the user to choose at the highest level between unstructured and structured data, as indeed is the case at every other level within msDescription. 2. All the sub-elements of , i.e. , , , , , and , are now optional (although itself is required), for reasons argued by TEI-MMSS. has been replaced with , which can contain any of the elements available within plus PCDATA (necessary for nicknames etc.). may now not appear anywhere other than as the first child of ; former shelfmarks etc. can be dealt with using , while references within the description to other MSS should use ref (or bibl). 3. The first-child level elements within pertaining to the description of the physical object (without the "meaningful inky bits"), viz.

, , , , , and , have been grouped under , which may, like other elements within , also simply contain p+. Other changes to include: * has been changed to , with a content model of p+ or one or more elements; * has been changed to , with a content model of p+ or one or more elements (previously called ). * , previously dealt with under has been added to . An attempt at grouping the other first-child level elements, , , and (i.e. marginalia) on the one hand, and , and on the other, was abandoned, chiefly owing to a lack of suitable nomenclature, although we may want to take this up again later. The content model for is thus: Outstanding issues: There is a number of outstanding issues, mostly pertaining to attributes and values thereof. Most prominent among these are: 1. Among the attributes on inherited from MASTER is: status CDATA (uni | compo | frag | def |unknown) #IMPLIED whereas TEIMMSS proposed: status (frag | def | unk) #IMPLIED composite (y | n | u) #IMPLIED The latter is better, as a manuscript can be both composite and defective, but it has also been argued that the composite or otherwsie nature of a manuscript can be determined by the presence or absence of elements (if a manuscript is composite, the description will contain one or more s; if it isn't, it won't). And there is still the problem that status refers to the manuscript rather than to the description, as one would expect (this is true also of the type attribute, which indicates the type of manuscript being described, not the type of msDescription). One solution would be to change status to e.g. msStatus, or to transfer it to another element or elements, for example and , but there is already a defective attribute available on and which essentially does the same thing. Perhaps neither is necessary. 2. Within the a.datable class we have: notBefore CDATA #IMPLIED notAfter CDATA #IMPLIED certainty (high|medium|low) #IMPLIED evidence (internal | external | attributed) #IMPLIED (attributed was formerly conjecture) There have been suggestions that evidence should be dropped and dating (or dateAttrib, as TEIMMSS called it) added, with possible values dated, datable, undatable, unknown. Do we want to do this? 3. Should the element within have or be turned into an attribute with a closed set of values? 4. Still outstanding is the question of what the values the type attribute on title should be, i.e. generic | distinctive or supplied | uniform (or both). 5. We agreed in Reykjavík to remove all attributes on other than type and subtype, i.e.: size CDATA #IMPLIED technique CDATA #IMPLIED style CDATA #IMPLIED quality CDATA #IMPLIED figurative (yes | no | na) #IMPLIED illustrative (y | n | n-a) #IMPLIED Do we really want to do this? The last two in particular could be useful. 6. Possible values for the type attribute on include role and female, but probably shouldn't. Decisions on these issues should obviously take into account the more general treatment of CDATA attribute values in P5. Matthew James Driscoll