[tei-council] <dimensions> reduex

[Lou Burnard]

My understanding of this issue may be summarised as follows.

1. MsDesc had an element <dimensions> which allowed either just text or 
some number the specialised elements <height> <width> <depth>

2. There was a consensus in favour of generalising these three rather 
specific not to say obsessive elements. A very early draft version of 
MsDesc had am element rather cutely named <dim> for this purpose

3. It was observed that <dim> was pretty close to the existing <measure> 
so maybe we should use the latter instead

I'd like us to agree on one of the following strategies

a. do nothing i.e. try to make <measure> function satisfactorily both as 
a measurement of quantity and as a statement of dimensions; live with 
the oddity of a <measureGrp> which doesnt just contain <measure>s

b. do some cosmetics  i.e. rename @extent as @quantity, <measureGrp> as 
<dimensions> etc as already discussed

c. revert  i.e. leave <measure> more or less as is, reintroduce 
<dimensions>, abolish <measureGrp>

If you choose (c)  then you need to decide between the following content 
models for <dimensions>

c-1 : text
c-2 : text | model.dimLike+
c-3 : text | model.dimLike.sequence

and you also need to decide whether the members of model.dimLike are --

d. height, width, depth
e. dim
f. dim, height, width, depth
g. dim, height, width, depth, measure

Assuming that we don't do (a), my recommendations are

c, c-2, f


Syd Bauman wrote:
> LB> Really, I think the best solution is to bring back <dimensions>!
> SB> [Maybe not best, but a good idea.]
> SR> yes. it would seem much more honest to have <dimensions> as a
> SR> container for text.
> CW> Then let the MS people have their dimensions. Seems like a good
> CW> compromise.
> 
> OK, as I'm still waiting for votes for or agin <ps> (about which I
> see Lou just posted) or more discussion on facsimile markup, I'll get
> going on this presently.
> 
>