[tei-council] reminder

[Gabriel BODARD]

Some suggestions:

(1) dimensions: maybe give at least one example of dimensions containing 
<dim> (perhaps diameter, which is probably more common than 
circumference). Also remove or correct the note at the end saying that 
this contains only height, width, and depth.

(2) height/width/depth: I still don't find the definitions of these 
elements very helpful (depth seems not to have changed, and still 
implicitly refers to a codex). Surely the height, width, and depth of an 
inscribed monument, for example, are defined not in relation to the text 
(which may be on any surface) but to gravity and the viewer, 
respectively. There must be a better description of these dimentions in 
archaeological terms (I'll see if I can find a reference...)

(3) att.dimensions: can we add an example of @extent containing a word 
such as "unknown" or "about half the page width", rather than just the 
(presumably deprecated) number+unit combination?

(4) att.ranging: might the (much misunderstood) relationship of 
@atLeast/atMost and @min/max be clarified slightly by the addition of 
"the approximate measurement" (for the former pair) and "more than one 
observation _or a range_" (for the latter)? Maybe someone can suggest an 
even better way to make this difference clear...? (@notBefore/notAfter 
and @from/to are better expressed on datable.)

(5) att.datable-w3c: picky correction, but <date when="0056">56 
AD</date> should of course read "AD 56".

(6) Probably outside the scope of "minor corrections", but I still amn't 
convinced by the numeric @degree attribute on certainty and precision. 
(It strikes me as an example of what a senior epigraphy coleague refers 
to as "spurious exactitude"--what does a precision of 0.5 mean?) Not 
wanting to upset those who habitually use numerals here, and even less 
so to break backward-compatibility, how about we add the existing 
attributes @cert (to certainty) and @precision (to precision), with 
their current suggested values 'low', 'medium', and 'high'?

(7) app: I note that the prose description of app seems not to have 
changed from the good old days when it could only be used to represent a 
set of variant readings. I'm pretty sure this has changed, and so the 
description, "May contain an optional lemma and one or more readings" is 
no longer true. App may now contain zero readings, and also some 
combination of model.global. Can the prose be updated to reflect this?

(8) expan: here is an example (which I should have supplied long ago) of 
expan used without choice:

<expan><abbr>Imp</abbr><ex>erator</ex></expan>

(I think this is better than 
<expan><abbr>Imp<am>p</am></abbr><ex>eratores duo</ex></expan> which 
just confuses matters, and probably belongs under "am" anyway...)

(9) lb: should we add an example of the usage of lb/type=word-dividing, 
which currently sits a little uncomfortably in the note. I suggest 
"Cae<lb type="worddiv"/>sari".

(9bis) I suppose it would be a little too controversial to suggest 
changing the expansion of 'lb' to "line begins" rather than line break?

(10) msDesc: can we add the words "or other text-bearing object" to the 
end of the description of this element?

(11) num: is there a good reason why <num> isn't part of att.ranging?

This should keep us going for now. ;-) (Sadly I'm not home and able to 
do a thorough read-through until July 2, but I'm sure I'll have more 
suggestions after that. I'm going to try to check the schema against a 
few tens of thousands of new files in the meantime. Will let you know 
how that goes.)

If they're disqualified from here, I'll put (6) and (11) in feature 
requests @ SourceForge.

Cheers,

Gabby

Lou Burnard wrote:
> Just a reminder that we'd like to get the error fixing release 1.4.1 out 
> as soon as possible. The plan (as James said last week) is to push the 
> button on 1 July, so you have four days left.
> 
> As James says: If we are going to do a maintenance release anyway, could 
> I humbly  suggest that Council members really scour the Guidelines and 
> reference pages making sure that we find any other errata or things that 
> we've implemented but not changed the related text about, or similar  
> omissions? We might as well try to fix as many bugs all at once!
> 
> A null report (i.e. "i looked at chapters x y and z and they seem fine") 
> is perfectly acceptable!

-- 
Dr Gabriel BODARD
(Epigrapher & Digital Classicist)

Centre for Computing in the Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL
Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/