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

[Lou Burnard]

Syd Bauman wrote:
> 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. 
>   
I didn't tangentially or otherwise imply any opinion on the <ps> 
proposal because I havent had time to read it yet. What I did say was 
that I thought getting such a feature into P5 1.0  was of less urgency 
or importance than progressing the work on digital facsimile editions to 
the point that it is usable in P5 1.0, and I still do!

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

This issue seems to me to be even further down the scale of importance 
than <postscript>
Does anyone know of any project (other than at Brown) which wants to use 
<measure> in the way that Syd seems to wish? However, not to appear 
churlish, here are some quick comments on this issue.

> * The <measure> element should have a quantity= attribute, not
>   extent= (and preferably not count=, although that's a lot better
>   than extent=).
>
>   
As already indicated, I have no problem with changing the name of the 
attribute (in fact I think I proposed it)

However all of Syd's subsequent points really boil down the fact that 
his view of what a generic <measure> element should be like turns out 
not to be able to support what people want to do when recording the 
measurements of manuscript page/s.

The Berlin Council meeting made the suggestion that we should try to use 
generic <measure> for this purpose, and I implemented what I understood 
was wanted, despite some misgivings about the fact that measurements of 
pages are rather different from quantities of stuff. This was done quite 
some time ago and till now no-one has complained about it.
> * <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>).
>   
It makes no difference whether the <measure> is generic or not. If I was 
obsessive enough to mark up as a measure sentences such as "The cart 
contained five six-gallon jugs" as
"five <measure>six gallon</measure> jugs" I could use @scope to 
indicate  whether all five were exactly 6 gallon jugs, or most of them 
were, or some of them were only 5.7 gallons.  I freely concede that to 
do this you'd have to completely mad, but that doesn't affect the issue 
of what the @scope attribute means.

> * The "suggested values include" list for unit= of <measure> should
>   be pretty much as all-encompassing as we can get it.
>
>   
I think this is a silly idea. We don't supply exhaustive lists of 
language identifiers, but refer to places where people can find them. 
Same applies to standard names for units.

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

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

see above.
> * 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).
>
>   
if you want <height> etc. to exist as specialisations of <measure> 
clearly you can suppress whatever attributes you like in them,

> * 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>.
>
>   

We used to have <measurements> but Council told us to take it away. I'm 
perfectly happy to bring it back.



> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>