Review of Tite Scheme
Jump to navigation
Jump to search
This work has been completed. See https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind0903B&L=TEILIB-L&T=0&F=&S=&P=73 for more information.
Contents
Background
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 <blort> element because we often categorize our texts by both their fooness and blortness.”.
- 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 Regarding Documentation
This section is for
- typos
- nit-picks
- suggested re-wording
- suggestions for re-arrangement of sections
etc.
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.
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 <TEI> 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
<teiHeader><!-- metadata --></teiHeader> <text> <front><!-- front matter --></front> <body><!-- body of text --></body> <back><!-- back matter --></back> </text>
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 <teiHeader> 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: <titePart> instead of <titlePart>(Mholmes)
comments on section 5.6
- "gap" seems like a phrase-level element, so shouldn't it be in section 6 instead?
comments on appendix b
- definition of "gap" contains cross-reference with "??" in it.
