LiteFinal
I spent much of today re-reading the February 2006 last revision of the TEI Lite document (tei_lite.odd) and asking myself the following questions
- is anything here actually wrong?
- is there anything here which I think is not useful?
- what topics do I think it might be useful to add ?
Obviously, the first category must be fixed. The only thing I've so far identified in this category is the assertion that the <teiCorpus> element cannot self-nest (#fail) -- it can now, as a result of some pretty good tidying up back in 2006. The initial chapter on the history of Lite itself also needs bringing up to date, and I have some draft text for that.
The other two are less clear, if only because "useful" really provokes the question "for whom?" and different answers arrive for the different responses to that question. So I would welcome comments on the tentative proposals I list here.
First off, let's not forget that the intention is not to rewrite this tutorial from scratch. If we were doing that, we probably wouldn't start from here but from TEI By Example, or from the earlier Council initiative spear headed by Peter Boot, or somewhere else. We'd also probably write it using a less dauntingly formal style today, though no-one seems to have complained about that recently.
The intention is just to continue to meet the original intentions of document TEI U5 which are summarised in the document itself roughly as follows :
- meet 80% of the needs of 80% of the current users of TEI
- provide a good basis for tutorials and generic introductory courses, etc.
- specifically to address two kinds of TEI application :
- "digital library" style straightforward encoding of early print materials
- "born digital" authoring of technical documents
With those audiences in mind, what needs adding or removing? Here are my initial thoughts, reading through the document.
- The discussion of the Jane Eyre example should be improved, for example to comment on the treatment of end-of-line hyphenation (is it honeymoon or honey-moon ?) Should the list of cool things following the example not be linked to the section in which said cool thing is discussed?
- should xml:base and xnl:space be removed from the schema? Neither is discussed -- if we keep them, they must be.
- Should the section on divisions warn against some vulgar errors (mono-div bodies, misuse of @n to contain <head> values, attempts to evade the tessellation requirement)?
- Should section 4.3 (and the schema) include discussion of <spGroup> ?
- A simpler prose drama example should be added to 4.3 before it launches into the complexities of overlapping hierarchies. It should be contrasted with the Fish example: which last should not use the @who attribute since this is explained later.
- "the names used for editions referred to by the @ed attribute... [is] documented in the header" Is it? But where?
- Should the discussion of @rend (6.1) mention the possibility of using CSS as value?
- In 6.2 we define q and quote but not said. My preference would be to remove quote, but if we add it we should either remove q or add said as well.
- I havent checked whether the discussion of xml:lang values in footnote in section 6.3 is still politically correct. Is it?
- Section 7 (just before the first example) has another vague reference to the Header, which should be made more precise or removed.
- Sections 8 and 9 seem to have stood the test of time quite well, and I see no need to modify them
- Should section 10 say something about linked data? At least a reference to the existence of the @ref attribute? (In that context, we should probably also include somewhere a comment that elements with a value for their xml:id attribute -- at the least the TEI element itself -- can ipso facto be exposed as LOD.
- Does section 12 (on bibliographies) need expanding?
- Should section 16 also contain a reference to egXML, and hence some discussion of name spaces? Should it at least explain what an ODD is?
- Is the extended example in 16.3 actually useful enough to keep? Wouldn't a brief discussion of what an ODD is and how you might use one to define your own technical manual be much more useful?
- Should the @facs attribute be added to the schema and to the discussion in section 14? I think so : lots of people produce simple Lite-based "digital editions"
- Is the treatment of front and back matter too detailed? Which parts would you remove? (Me, I love it all; except maybe the list of suggested values for @types of prefatory matter)
- Something went wrong (probably a rogue #uri) at the end of section 18 sv "index"
- 19.1.4 should probably include an example using <licence> . OTOH, I think elements <notesStmt> and <biblFull> could probably go.
- 19.3 needs an example of using >catRef
- 19.4 might profitably say that there better ways of handling revision history
- The appendix "Substantive changes from the P4 version" should go. It's out of date and incomplete.
