[tei-council] reminder

[Lou Burnard]

Thanks for these Gabby. I've just made the following changes:
>
>
> (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.
>

I didn't use diameter, because then I'd have to decide how it differed 
from "width". But I did add another example, and removed the 
superannuated note.


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

Had another go at improving those definitions. Dont expect you'll like 
these any better though.

> (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?
>
Done

> (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.)
>
I am not sure that these are much less likely to be misunderstood, but 
have adopted them anyway

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

OK, done

> (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'?
>

As you say, this is not a minor correction, so nothing done.

> (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?
>
Yes: I zapped another superannuated <remarks> element
> (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...)
>

Couldn't find the latter eg, but have added the former.
> (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".
>

Don't know what note you're referring to. Don't see the point of the 
@type attribute. Haven't done anything.

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

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

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

None that I can think of. Done.