[tei-council] time is running out ... <measure> and <ps>

[Syd Bauman]

Christian (and all) --

We need to decide what we are going to do, if anything, with
<ps> and <measure> pretty fast. 


On <ps>
-- ----
As per council's request in Berlin, rather than checking <ps> into
P5, I ripped it out and made a stand-alone ODD of it
(http://www.tei-c.org/Drafts/ps/). The ostensible point of this
exercise was that having an element to encode postscripts is
controversial enough that it was too scary for me to check it
directly into P5. This means, IMHO, that we need an explicit vote to
include this element in P5 or not. I think we need to make this
decision ASAP.

So far Sebastian has said he thinks it should go in, and Lou has
tangentially implied that he doesn't. I am in favor of including it. 


On <measure> et al.
-- --------- -- ---
I think the current situation is broken. I am quite confident, e.g.,
that at least 2 of the projects I work with at Brown would re-define
<measure> (to be roughly what it used to be) rather than use it as it
is now.

* The <measure> element should have a quantity= attribute, not
  extent= (and preferably not count=, although that's a lot better
  than extent=).

* <measure> should not have a scope= attribute (unless someone wants
  to put in some work figuring out what a scope= might usefully mean
  for a generic <measure>).

* The "suggested values include" list for unit= of <measure> should
  be pretty much as all-encompassing as we can get it.

* The <height>, <width>, and <depth> elements should not have a
  commodity= attribute.

* The <height>, <width>, and <depth> elements should have a scope=
  attribute (they currently do; the point of my saying this is to
  contrast it with <measure>).

* The "suggested values include" list for unit= of <height>, <width>,
  and <depth> should be very limited (the list that is currently
  there looks good to me; again the point of mentioning this is that
  it is very different from unit= of <measure>, for which the current
  list seems inappropriate to me).

* The amount attribute on <height>, <width>, and <depth> could be
  named quantity= or extent=, or for that matter, value=.

In tabular form, what I think we should do could be summarized as
follows.
                                          <height>, 
                <measure>                 <width>, and
                                          <depth>
                ----------------          ---------------------
name of                                   
amount                                    
attribute:      quantity=                 extent=

scope=          no                        yes

suggested       extensive                 very short      
values for      semi-closed               closed or semi-closed
unit=:          list                      list


In addition, I think that <measureGrp> should not have text content.
If Council is persuaded by Lou's arguments as to why it should have
textual content ("As I remember the discussion, we recognises that
most institutions would always supply dimensions in their own
specific sequence, and might not want therefore to tag the height
etc. explicitly. Compare the <geo> element, which just knows that you
give lat and long in that order.") rather than my counter argument
(which boils down to "for consistency grouping elements should not
have textual content, and <geo> is a poor model, as it is poorly
defined"), then we should come up with a different name, like
<measurements> or <measurementSet>.