Difference between revisions of "LiteFinal"
Jump to navigation
Jump to search
LouBurnard (talk | contribs) |
LouBurnard (talk | contribs) |
||
| Line 30: | Line 30: | ||
# Should the discussion of @rend (6.1) mention the possibility of using CSS as value? ''No, absolutely not, in my opinion. [JC] NO!!!!!!! [SR] I'm surprised MH has not expressed a view on this (to my mind) reasonable proposition [LB]'' | # Should the discussion of @rend (6.1) mention the possibility of using CSS as value? ''No, absolutely not, in my opinion. [JC] NO!!!!!!! [SR] I'm surprised MH has not expressed a view on this (to my mind) reasonable proposition [LB]'' | ||
# 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. ''document <said> [SR] I'd probably add said. [JC]'' ''But then why not remove q? [LB]'' | # 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. ''document <said> [SR] I'd probably add said. [JC]'' ''But then why not remove q? [LB]'' | ||
| − | # I havent checked whether the discussion of xml:lang values in footnote in section 6.3 is still politically correct. Is it? '' | + | # I havent checked whether the discussion of xml:lang values in footnote in section 6.3 is still politically correct. Is it? ''The document it points to has been deprecated. Should it point instead to: http://www.loc.gov/standards/iso639-2/php/code_list.php ? [JC] pass [SR]'' |
| − | The document it points to has been deprecated. Should it point instead to: http://www.loc.gov/standards/iso639-2/php/code_list.php ? [JC] pass [SR]'' | ||
# Section 7 (just before the first example) has another vague reference to the Header, which should be made more precise or removed. ''Agreed, should be made more precise. (Though I'm not entirely sure what it should say.) [JC] pass [SR]'' | # Section 7 (just before the first example) has another vague reference to the Header, which should be made more precise or removed. ''Agreed, should be made more precise. (Though I'm not entirely sure what it should say.) [JC] pass [SR]'' | ||
# Sections 8 and 9 seem to have stood the test of time quite well, and I see no need to modify them ''In 8.3 @ana "links an element with its nterpretation" maybe shouldn't be singular? 'one or more interpretations'. Otherwise, nothing jumped out at me. [JC] pass [SR]'' | # Sections 8 and 9 seem to have stood the test of time quite well, and I see no need to modify them ''In 8.3 @ana "links an element with its nterpretation" maybe shouldn't be singular? 'one or more interpretations'. Otherwise, nothing jumped out at me. [JC] pass [SR]'' | ||
| − | # 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. ''Maybe two sentences, one of the @ref attribute and one on what a good idea putting @xml:id's on things are since it simplifies | + | # 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. ''Maybe two sentences, one of the @ref attribute and one on what a good idea putting @xml:id's on things are since it simplifies people pointing into their files. Otherwise, I wouldn't get into LOD etc. here. [JC] not now. one day [SR]'' |
| − | people pointing into their files. Otherwise, I wouldn't get into LOD etc. here. [JC] not now. one day [SR]'' | ||
# Does section 12 (on bibliographies) need expanding? ''I'd vote no. You'd want to change it too much. [JC] no. too many dragons [SR]'' | # Does section 12 (on bibliographies) need expanding? ''I'd vote no. You'd want to change it too much. [JC] no. too many dragons [SR]'' | ||
# 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? '' I'd drop 16.1 entirely. [SR] Unlike SPQR, I'd leave 16.1 and include a link to the USE chapter explaining that these are more elements are used for storing TEI customisations. [JC]'' | # 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? '' I'd drop 16.1 entirely. [SR] Unlike SPQR, I'd leave 16.1 and include a link to the USE chapter explaining that these are more elements are used for storing TEI customisations. [JC]'' | ||
# 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? ''While I'd probably like that this isn't a manual for me. I'd leave it as is. [JC] pass [SR]'' | # 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? ''While I'd probably like that this isn't a manual for me. I'd leave it as is. [JC] pass [SR]'' | ||
# 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" ''yes, put in @facs. good idea. [SR] Yes, add @facs and document very briefly (point to chapter for more information?) [JC]'' | # 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" ''yes, put in @facs. good idea. [SR] Yes, add @facs and document very briefly (point to chapter for more information?) [JC]'' | ||
| − | # 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) ''dunno. I kind of like that stuff well, up to 19.2 at least. but probably leave alone [SR] Leave it. (But yes, | + | # 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) ''dunno. I kind of like that stuff well, up to 19.2 at least. but probably leave alone [SR] Leave it. (But yes, otentially nuke suggested values of @type there.) [JC]'' |
# Something went wrong (probably a rogue #uri) at the end of section 18 sv "index" ''yes. That should be fixed. [JC]'' | # Something went wrong (probably a rogue #uri) at the end of section 18 sv "index" ''yes. That should be fixed. [JC]'' | ||
# 19.1.4 should probably include an example using <licence> . OTOH, I think elements <notesStmt> and <biblFull> could probably go. ''Yes, include licence, keep notesStmt, ditch biblFull would be my vote. [JC]'' | # 19.1.4 should probably include an example using <licence> . OTOH, I think elements <notesStmt> and <biblFull> could probably go. ''Yes, include licence, keep notesStmt, ditch biblFull would be my vote. [JC]'' | ||
| − | # 19.3 needs an example of using > | + | # 19.3 needs an example of using <catRef> ''potentially [JC]'' |
| − | # 19.4 might profitably say that there better ways of handling revision history | + | # 19.4 might profitably say that there better ways of handling revision history ''It might point out that these change elements can be updated by proper version control systems. (But I'd stay vague and neutral on what those are and how to do so.) [JC]'' |
| − | # The appendix "Substantive changes from the P4 version" should go. It's out of date and incomplete. | + | # The appendix "Substantive changes from the P4 version" should go. It's out of date and incomplete. ''Agreed.[JC]'' |
Revision as of 17:49, 28 July 2012
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? Yes, the discussion could be improved slightly, and yes, the list could point to the appropriate sections of the TEI Guidelines. (However, I would point to the Vault version for which this version of TEI Lite is fixed against.)" [JC] "maybe. not urgent?" [SR]
- should xml:base and xml:space be removed from the schema? Neither is discussed -- if we keep them, they must be. "no, its weird to remove standard XML things" [SR] "Remove them." [JC]
- 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)? "no. leave sleeping dogs [SR]" "If so, only very briefly." [JC]
- Should section 4.3 (and the schema) include discussion of <spGroup> ? "No, that sounds heavy not Lite." [JC] "pass" [SR]
- 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. "Yes, simpler prose drama would be good. [JC] "ok" [SR]
- "the names used for editions referred to by the @ed attribute... [is] documented in the header" Is it? But where? pass [SR] Using editionStmt mentioned further down? [JC] Surely not -- that is for edition of the digital resource not its source [LB]
- Should the discussion of @rend (6.1) mention the possibility of using CSS as value? No, absolutely not, in my opinion. [JC] NO!!!!!!! [SR] I'm surprised MH has not expressed a view on this (to my mind) reasonable proposition [LB]
- 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. document <said> [SR] I'd probably add said. [JC] But then why not remove q? [LB]
- I havent checked whether the discussion of xml:lang values in footnote in section 6.3 is still politically correct. Is it? The document it points to has been deprecated. Should it point instead to: http://www.loc.gov/standards/iso639-2/php/code_list.php ? [JC] pass [SR]
- Section 7 (just before the first example) has another vague reference to the Header, which should be made more precise or removed. Agreed, should be made more precise. (Though I'm not entirely sure what it should say.) [JC] pass [SR]
- Sections 8 and 9 seem to have stood the test of time quite well, and I see no need to modify them In 8.3 @ana "links an element with its nterpretation" maybe shouldn't be singular? 'one or more interpretations'. Otherwise, nothing jumped out at me. [JC] pass [SR]
- 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. Maybe two sentences, one of the @ref attribute and one on what a good idea putting @xml:id's on things are since it simplifies people pointing into their files. Otherwise, I wouldn't get into LOD etc. here. [JC] not now. one day [SR]
- Does section 12 (on bibliographies) need expanding? I'd vote no. You'd want to change it too much. [JC] no. too many dragons [SR]
- 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? I'd drop 16.1 entirely. [SR] Unlike SPQR, I'd leave 16.1 and include a link to the USE chapter explaining that these are more elements are used for storing TEI customisations. [JC]
- 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? While I'd probably like that this isn't a manual for me. I'd leave it as is. [JC] pass [SR]
- 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" yes, put in @facs. good idea. [SR] Yes, add @facs and document very briefly (point to chapter for more information?) [JC]
- 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) dunno. I kind of like that stuff well, up to 19.2 at least. but probably leave alone [SR] Leave it. (But yes, otentially nuke suggested values of @type there.) [JC]
- Something went wrong (probably a rogue #uri) at the end of section 18 sv "index" yes. That should be fixed. [JC]
- 19.1.4 should probably include an example using <licence> . OTOH, I think elements <notesStmt> and <biblFull> could probably go. Yes, include licence, keep notesStmt, ditch biblFull would be my vote. [JC]
- 19.3 needs an example of using <catRef> potentially [JC]
- 19.4 might profitably say that there better ways of handling revision history It might point out that these change elements can be updated by proper version control systems. (But I'd stay vague and neutral on what those are and how to do so.) [JC]
- The appendix "Substantive changes from the P4 version" should go. It's out of date and incomplete. Agreed.[JC]
