Reviews of the manuscript description chapter have been received from: Dorothy Dot Porter (DP), working with Ben Withers, professor in Art History, University of Kentucky, who is producing an electronic edition of BL Claudius B. iv. Elizabeth Solopova (ES) at the Bodleian Torsten Schaßan (TS) of the Herzog August Bibliothek in Wolfenbüttel Jindrich Marek (JM) of the National Library of the Czech Republic Gautier Poupeau (GP) of the Sorbonne Additional comments were received from Fotis Jannidis (FT), Darmstadt, and from Consuelo Dutschke (CD), Columbia University Library; the draft currently available has been amended to take these comments into account. I should like to thank all these people for the considerable effort they have put into these reviews, which have been extremely helpful to us in finalising the draft of this chapter.

The reviewers point out many small errors and inconsistencies, some owing to the nature of the ODD system, such as statements in the specifications that elements have no attributes other than global and inherited ones, when according to the surrounding prose in fact they do (about a dozen of these are mentioned by TS), and descriptions of standard TEI elements or attributes which are inappropriate to manuscripts, for example extent, mentioned by almost everyone (GP feels that extent, which has a clearly defined purpose in the teiHeader, should not be used for something entirely different here).

Some classic problems turned up again, such as the apparent inflexibility of the system when dealing with legacy data: the fact that one cannot, for example, take physDesc before msContents, which is precisely what the majority of printed catalogues do (ES). In this and a few other cases it is doubtful whether revisiting these issues now would be profitable; in other cases, however, it is clear that adequate solutions remain to be found to some of these problems.

There were also a number of comments which were simply wrong (people saying that you couldn't do things you in fact can); these, in some cases at least, indicate that the documentation needs to be better.

In addition to obvious mistakes, inconsistencies and lacks, which have been or are being dealt with, the following may be mentioned as suggestions for improvement on which action might be taken (comments on these would be gratefully received):

1. One problem which was mentioned by several people has to do with the change of msHeading to the standard TEI element head, one result of which is that it is no longer possible to use textLang to indicate the language of the manuscript as a whole (textLang is allowed within individual msItem elements but is not, unlike origPlace, origDate and title, phrase-level). There is, of course, nothing to stop you simply writing Latin with some French in your head element, but for search purposes and so on people will probably want to tag these things. One solution that occurs to me is to have the relevant attributes from textLang, viz. langKey and otherLangs, on msContents; another would be simply to make textLang phrase-level. Doing either of these would also allow one to encode the languages of the manuscript even if one used the p option inside msContents, as requested by ES. (ES suggests textLang is also needed elsewhere, e.g. in provenance to indicate the languages used in ownership notes, but the xml:lang attribute can be used for such purposes). The inability to have author in head was also mentioned (e.g. by JM), but this is largely, one suspects, a result of its having been possible in MASTER; if one feels strongly about it, one can always wrap author and title inside a bibl.

2. Not for the first time, there is a request for a type attribute on bibl, which would be extremely helpful for sorting, searching and general output (ES). In theory I agree (and proposed this myself on an earlier occasion); for what it's worth, we decided at the AMI that it was necessary to distinguish between editions of texts on the one hand and scholarly discussions of a philological nature on the other, and that there should also be a distinction between scholarly discussion which is based on first-hand investigation and that which is secondary in the sense that it derives not from an examination of the primary sources themselves but from other published materials. A third group consists of references which are no more than that, i.e. which add nothing to the discussion and are therefore unlikely to be of interest to the scholar. Similarly, we decided to distinguish between types of editions. In order to distinguish between the various types of secondary material and text editions we use a type attribute on ref (within bibl), with the values primary and secondary plus a number to indicate the level. We put the type attribute on ref since such ratings are only applicable to the bibliographical references in the individual msDescription elements, as the same work will inevitably have varying levels of relevance to different manuscripts.

3. Several reviewers queried the meaning and use of the type and status attributes on msDescription. These have long been problematic and are still in need of sorting out. The intention with the type attribute was to distinguish at the very top (as it were) between manuscripts proper and archival material (charters etc.). The inspiration for this came, as far as I can remember, from EAMMS and/or Digital Scriptorium, which had a simple tick-box: document yes/no; this was taken over in MASTER as type="document", with no alternative. As pointed out by TS, the form attribute on objectDesc provides the same information. The status attribute is defined as specifying the compositional status of a manuscript or manuscript part and has the possible values uni, compo, frag, def or unknown. It has been pointed out that, for one thing, this should probably be called msStatus or something similar, since it refers to the status of the manuscript and not of the description, and for another that it is prefectly possible for a manuscript to be both composite and defective, which is why TEI-MMSS proposed splitting this attribute into two: status, with possible values frag, def and unknown, and composite, with possible values yes, no or unknown. It has also been pointed out that the distinction between uni and compo is in any case inferable from the presence or absence of msPart elements, while a manuscript which is defective will have defective="true" on msContents or msItem. Thus the only possible value of status which cannot be inferred from other places in the document is frag; this was always potentially problematic anyway, as the distinction between a fragmentary and a defective manuscript is somewhat arbitrary. I am not sure we need an attribute to indicate the completeness or otherwise of the description itself, as TS would like to see, since this would be better dealt with under recordHist. So my feeling is - drop 'em both.

4. TS says that the element dimensions is extremely narrow and needs to be opened up to what it was in MASTER, or substituted at the phrase-level with measure, which allows for human readable content. I don't think we need to open up dimensions, but perhaps measure ought to be proposed as a less structured alternative? TS gives an example in his comments on extent: <extent> <measure type="leaves">10 Bl.</measure> <measure type="dimensions">37 x 29 cm</measure> </extent> Regarding these two elements, GP points out that key is available as an attribute on measure but not on dimensions; this is true, but I am not sure I see what its usefulness there would be.

5. Several people, TS and CD among them, mention that it needs to be made more explicit where the elements origDate and origPlace can (or should) appear. TS suggests that they should only appear in three places: in head, in binding (since the binding might have been done at a time and place different from the text) or in origin, which he says is the natural place for this kind of information. I have myself often wondered whether these elements should be allowed everywhere (as, being phrase-level, they are at present), or even if they are whether their use in more than one place should not be discouraged? A case could be made, it seems to me, that they should appear only once in each msDescription (or msPart). Furthermore, it has never been clear to me where the attributes notBefore and notAfter should go (i.e. on origPlace, on origin, on both?).

6. In analogy to the class tei.datable TS proposes tei.placeable, of which (at least) the element origPlace should be a member; it would contain the attributes placeAttrib, with possible values localized, localizable and unknown, and evidence with the values internal, external and attributed (presumably also certainty, which he doesn't mention). This is, it seems to me, a good suggestion. Apropos datable things, GP wonders why the elements date and docDate are not members of the tei.datable class. A good question, to which I have no answer.

7. TS points out an inconsistency between bibl and msItem in that biblStruct, which was a more structured bibl, has been removed in favour of biblItem, which contains the structured content; msItem, on the other hand, contains the unordered content whereas the structured content goes into msItemStruct. This is a valid point, but what to do about it? Several other people, GP among them, thought the difference between msItem and msItemStruct was not explained clearly enough. This section has been completely rewritten and is now, I hope, clearer. I still wonder, though, whether anybody (other than David Birnbaum, for whom it isn't restrictive enough anyway) actually needs msItemStruct.

8. TS agrees with CD that the two attributes attested and accepted on the element author (as allowed in MASTER) were very useful and should be reinstated. The problem here, I assume, is that author is a standard TEI elements and thus cannot be redefined in another context. If the notions they represent are so different in these two contexts the only solution is to come up with new special-purpose element, e.g. msAuthor (there are obviously many examples of this already). I wonder, however, whether they really are so different, or whether what differences there are can't be dealt with using the existing respStmt element. GP, incidentally, would like to be able to include respStmt at various places in the physical description, so as to be able to indicate the names of les différents intervenants dans la conception physique de l'ouvrage. While I agree wholeheartedly with the idea behind this, I think the same result can be achieved using the mechanisms proposed for prosopographic information generally (key on name pointing to a person element); here again, however, the removal of the role attribute on name does not allow one to distinguish between different roles played by the same person (the same person could be the scribe of one manuscript and the owner of another). This is a problem which really does need to be sorted out; the most obvious way of doing this would be to reinstate role, or, if that's not acceptable (on the grounds that names don't have roles, other than naming things), coming up with another name (persRole perhaps?).

7. Several reviewers felt that the over-all structure of physDesc was illogical or inadequate, and the sections describing it confusing. JM suggests, for example, that the encoding of watermarks should be done not within material but in a specialised watermarksDesc element, containing one or more watermark elements. It is clear that the mechanism for dealing with watermarks is at present only very rudimentary, and this is certainly one direction in which future work might lead us, but I am not persuaded that this change needs to be made now. JM also argues that instead of objectDesc form="codex" there should be a form element; there was a form element in MASTER, which the task force agreed was unnecessary, and I must admit that I see no reason to reinstate it now. JM also says that the material attribute on supportDesc is unnecessary, given the availability of the material element within it (which even has a type attribute, allowing one, in theory, to provide the same information three times). I agree that using both the attribute and the element is a bit belt-and-braces, but I don't see anything wrong with offering people alternatives. ES complains that decoNote elements can't be grouped in a list and provided with a heading, but I don't see that the same effect can't be achieved by using list within decoDesc, i.e. where decoDesc is used to describe a type of decoration, rather than a particular instance of decoration (the documentation makes clear that both these are possible); this is, in fact, precisely what has been done by DP, who declares herself satisfied with the result.

8. The structure of handDesc was commented on by several people. TS notes that in real catalogues you mostly find descriptions with an introductory statement followed by descriptions of one or more hands, sometimes followed by concluding statements, as in the following (invalid) example: <msWriting hands="4"> <date>Early 9c</date> <term type="fontDescription">littera carolina</term> Four hands, each writing one complete gospel: <handDesc scribe="Hiltfredus">A: <locus>ff. 2r-54r</locus> (= Hiltfredus)</handDesc>; <handDesc scribe="B">B: 56r-90r</handDesc>; <handDesc scribe="C">C: 92r-152r</handDesc>; <handDesc scribe="D">D: 153r-194r</handDesc>. </msWriting> Since this kind of structure cannot be encoded using the current model for handDesc, he says, one possible solution might be to reinvent the element msWriting, with the attribute hands and children p or handDesc. handDesc might have a mixed content model with handNote as its main child. Alternatively, handNote or just hand could be made a phrase-level element, which would allow for its use within p. GP, for his part, bewails the fact that there is a degree of overlap between the system proposed here for describing hands (handDesc) and the existing system in chapter 18 and asks whether it wouldn't be intéressant to try and merge the two systems. Trés intéressant, I should have thought. This is clearly an area in need of further work.

9. Finally, TS says that it would be nice if bibliographical information (or a link) were provided for the manuscript descriptions from which the examples have been taken so that one could see how they fit into the record as a whole. This is a good idea, the only problem being that some of the examples are made up for the purpose while others are (or were once) real; still, the longer ones are likely to be real, and I suppose one might, as a matter of principle, only use real examples in the TEI guidelines.