Review of Tite Scheme

TEI in Libraries: Home

Background
Call for feedback

TEI Tite itself

Comments Regarding the TEI Tite Encoding Language
This section is for comments about the encoding language itself, preferably with use cases to support them. E.g. “At Blort University we would want you to add a foo= attribute to the element because we often categorize our texts by both their fooness and blortness.”.

Comments Regarding Documentation
This section is for etc.
 * typos
 * nit-picks
 * suggested re-wording
 * suggestions for re-arrangement of sections

general comments

 * Incorporate outside documentation (for example, Virginia's DLPS documentation) into this document so it can stand alone. (This was suggested by Andrew Rouner at the SIG meeting in London.) (Kshawkin)
 * House editorial style for examples in the TEI Guidelines use XML comments, not square brackets, to delimit areas of element content that are excluded for readability of the example. Using the same approach in the Tite will make it more consistent with, and thus more readable alongside, the TEI Guidelines.
 * Need to include g element in order for Tite to be used in Far East projects. (This was suggested by Marcus Bingenheimer at the SIG meeting in London.)

comments on section 1

 * “RelaxNG” should be spelled “RELAX NG” for short (or “ISO/IEC 19757-2: Document Schema Definition Languages part 2 — Regular-grammar-based validation” for long)
 * We should either include Vesta as a tool that can generate schemas from the ODD, or at least prepare for doing so by replacing “The Roma web tool can generate all of these.” with “Software utilities, including the Roma web tool, can generate each of these derived products.” or some such.
 * “… encoding through constraint, constraint via its …” would read better as just “… encoding through constraint via its …”.
 * It would be nice if the CSS did something with.

comments on section 2.2

 * It is probably worth saying how to encode hard and soft hyphens. Something like “Hard hyphens should be transcribed as the HYPHEN-MINUS character generally available on Wesetern keyboards (i.e. U+002D). Soft hyphens, when transcribed, should be transcribed as SOFT HYPHEN (i.e., U+00AD).”

comments on section 2.5

 * “… close to hand.” should be “… close at hand.”, IMHO. (Syd)
 * “In any case like this where there is doubt or difficulty, …” may be easier to read if reduced to “In such cases …”.

comments on section 3.1

 * The example shows the  root element in no namespace. TEI documents, of course, need to be in the TEI namespace. Howver, house style for the TEI Guidelines does not include the xmlns= attribute in examples, either.


 * In the example, “TEI Header information” seems redundant. Thus

comments on section 3.2

 * “PUBLIC . . . >” should read “PUBLIC …>”.


 * The reader should be explicitly reminded that so long as a text does not have its  attached yet, it is not a proper TEI document.


 * “… content model for Tite is taken verbatim from the TEI Tite, thus …” should be “… content model for Tite is taken verbatim from TEI Lite, thus …”.

comments on section 3.5

 * Typo in the documentation:  instead of (Mholmes)

comments on section 5.6

 * "gap" seems like a phrase-level element, so shouldn't it be in section 6 instead?

comments on section 6

 * As suggested by Marcus Bingenheimer: add "g" as an allowed phrase-level element . If this element is not allowed, there's no hope that Tite will be adopted by users in the Far East.

comments on appendix b

 * definition of "gap" contains cross-reference with "??" in it.