Difference between revisions of "Review of Tite Scheme"
Jump to navigation
Jump to search
(Add some comments and some structure for these and future comments) |
m (→Comments: a bunch more) |
||
| Line 23: | Line 23: | ||
* 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).” | * 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. ([[User:Syd|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. | ||
| + | |||
| + | * 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. Also, “TEI Header information” seems redundant. Thus | ||
| + | <pre><nowiki><teiHeader><!-- metadata --></teiHeader> | ||
| + | <text> | ||
| + | <front><!-- front matter --></front> | ||
| + | <body><!-- body of text --></body> | ||
| + | <back><!-- back matter --></back> | ||
| + | </text></nowiki></pre> | ||
| + | |||
| + | ===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=== | ===comments on section 3.5=== | ||
* Typo in the documentation: <titePart> instead of <titlePart>([[User:Mholmes|Mholmes]]) | * Typo in the documentation: <titePart> instead of <titlePart>([[User:Mholmes|Mholmes]]) | ||
Revision as of 17:50, 17 January 2009
Contents
Background
Comments
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)
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.
- 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. Also, “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)
