[tei-council] oversimplification: <measure> isn't measured

[Syd Bauman]

SB> In Berlin the TEI Council requested the creation of a new element,
SB> <measureGrp>, which would replace the special-purpose <dimensions>
SB> element. Was part of the point of this exercise to eliminate the
SB> special-purpose <height>, <width>, and <depth> as well, using (e.g.)
SB> <measure type="height"> or some such instead?

LB> No, I don't think so. 

Check. Anyone else have a useful recollection on this?


LB> The specific elements are permitted as children of <measureGrp>
LB> as an alternation to text.

Yes, right, this is currently the case, but I do not think text
should be permissible in the content of <measureGrp>. I cannot come
up with a good reason to use use an element that groups measurements
with anything other than elements from model.measureLike, let alone
plain text, as its content. Can you provide an example of how this is
useful? (But note that I am explicitly saying the in the simple case
of
    <measureGrp> 7 x 12 </measureGrp>
it is not useful.)


LB> As I remember the discussion, we recognises that most
LB> institutions would always supply dimensions in their own specific
LB> sequence, and might not want therefore to tag the height etc.
LB> explicitly. 

I don't remember any such conclusion, and don't think it is a good
reason to violate the principle of what a <*Grp> element is. Is it
really that tough to use 
  <height>7</height> <width>12</width>
instead of
  7x12
? Perhaps I'm being a holier-than-thou bigot here, but I don't see
anything wrong with telling those institutions who always do supply
dimensions in their own specific order "too bad, you have to
explicitly say which is which anyway" (at least, if you want to use
<measureGrp>). 


LB> Compare the <geo> element, which just knows that you give lat and
LB> long in that order.

Indeed. As far as I can tell, <geo> is underspecified[1], but even it
gives a default order: latitude then longitude. The imagined use of
<measureGrp> here doesn't even specify a default order, so that if I
come across "7x12" I don't know which is height and which is width,
or if one of them is actually depth. In manuscript description these
terms are defined, and the difference matters, no?


SB> ... <measure> ... has traded in its quantity= attribute for an
SB> extent= attribute.

LB> I agree "extent" is a slightly strange name for this: how about
LB> @count?

Well, count= is certainly better than extent=. But it is really only
correct for measurements of countable things like "1 dozen roses"; it
still isn't quite right for uncountables, like "66.95 mL", or even
"12 in". I think the right attribute name is "quantity".

The Brown STG <measure> element upon which the P5 0.5 <measure>
element was based used count= -- one of the few improvements we made
was to change the name of this attribute to quantity=. It was a good
idea then, and I still think it is.


SB> ... the "suggested values include" list for unit= has lost all
SB> the suggested values that don't make sense when measuring a page.

LB> The international standard is referenced, and I've certainly no
LB> objection to adding a few more examples taken from it

While I think a few more examples is far better than none, what I
don't understand is why not all of them? Why make a poor user go off
and read SI or NIST documentation, rather than just give her a nearly
comprehensive list of values? When she goes to enter a unit=, oXygen
would pop up the list with its glosses and descriptions, and she can
easily discover that she should use "kg", not "Kg" for kilograms, and
"in", not "inch" for inches.


SB> * move <measure> back to att.measurement

LB> Cant see anything to be gained by doing this, other than the
LB> confusion of now having two classes with the same meaning

But my point is that they don't have the same meaning. One is general
purpose for which commodity= and a long "semi" list of possible
values makes sense, but for which scope= is at least underspecified,
if it makes sense at all; the other is very special-purpose, for
which commodity= is always already known, scope= makes sense, and the
list of possible values should be quite limited.

This is a case where splitting is more helpful to the end user than
lumping. 


SB> * remove text from content of <measureGrp>? (if it seems important,
SB>   put model.pLike in?)

LB> Not a good idea in my view, for reasons given above

I disagree. I cannot see any reason why

  136 folios:
  <measureGrp> 280 x 190 </measureGrp>.
  Twenty-three quires of eight ...

is significantly superior to

  136 folios: 280 x 190.
  Twenty-three quires of eight ...

If one is going to bother putting a <measureGrp> in, then why not
make it useful for processing:

  136 folios:
  <measureGrp> 
    <height unit="mm">280</height>
    <width unit="mm">190</width>
  </measureGrp>.
  Twenty-three quires of eight ...


Notes
-----
[1] Many, if not most, users will want to know what syntax to use for
    expressing latitude and longitude. WGS 84, as far as I can tell,
    provides no guidance here at all. Are they expressed as degrees,
    minutes, and seconds, or as decimal degrees? With compass
    direction, or using signed values? What symbols, if any, are used
    to indicate the unit(s)? What separates the latitude from the
    longitude? But for that matter, these TEI guys use "2" to mean
    "female", maybe they want longitude expressed in radians (but if
    so, signed values < pi or unsigned < 2*pi? :-)
    While I'm at it, I noticed that <geoDecl> is a member of
    att.declarable, but that <geo> is not a member of att.declaring;
    is the presumption that all of the <geo>s in a given <div> will
    always use the same <geoDecl>?