[tei-council] Lite Final

Thu Jul 26 11:30:30 EDT 2012

On 26/07/12 15:30, Lou Burnard wrote:
> This contains 22 questions. You can answer them either there
> (but remember to sign you answer) or in an email here.

My votes below.

> 1. 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.)

> 2. should xml:base and xnl:space be removed from the schema?
> Neither is discussed -- if we keep them, they must be.

Remove them.

> 3. 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)?

If so, only very briefly.

> 4. Should section 4.3 (and the schema) include discussion of
> <spGroup> ?

No, that sounds heavy not Lite.

> 5. 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.

> 6. "the names used for editions referred to by the @ed
> attribute... [is] documented in the header" Is it? But where?

Using editionStmt mentioned further down?

> 7. Should the discussion of @rend (6.1) mention the
> possibility of using CSS as value?

No, absolutely not, in my opinion.

> 8. 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'd probably add said.

> 9. 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 ?

> 10. 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.)

> 11. 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 interpretation" maybe 
shouldn't be singular? 'one or more interpretations'.  Otherwise, 
nothing jumped out at me.

> 12. 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.

> 13. Does section 12 (on bibliographies) need expanding?

I'd vote no. You'd want to change it too much.

> 14. 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?

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.

> 15. 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.

> 16. 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, add @facs and document very briefly (point to chapter for 
more information?)

> 17. 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)

Leave it. (But yes, potentially nuke suggested values of @type 
there.)

> 18. Something went wrong (probably a rogue #uri) at the end of
> section 18 sv "index"

yes. That should be fixed.

> 19. 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.

> 20 19.3 needs an example of using >catRef

potentially

> 21. 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.)

> 22. The appendix "Substantive changes from the P4 version"
> should go. It's out of date and incomplete.

Agreed.

-James

-- 
Dr James Cummings, InfoDev,
OUCS, University of Oxford