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

Syd Bauman Syd_Bauman at Brown.edu
Thu Jul 5 00:45:05 EDT 2007


On the one hand, I couldn't agree with you more, David: we do pay a
heavy price for the class system, and in some cases I doubt it is
worth it. But I suggested a model of
  dimension*
with attributes for height, width, and depth as a better alternative
to what we have now:
  ( height | width | depth )*
as opposed to what would be really nice control:
    height, width, depth?

(BTW, I think I used the name <extent> in the previous post, which is
a bit silly, as that name is already taken. Of course, we could use
that same element ... the semantics aren't all that different.)

I have to think about the argument that it is easier to create a
customization that expresses control if we leave the three separate
elements. It is not all that hard with only one.

    <rule context="tei:msItemStruct//tei:measureGrp">
      <assert test="count(./tei:dimension[@type='height'])=1">
        Need one (and only one) height
      </assert>
      <assert test="count(./tei:dimension[@type='width'])=1">
        Need one (and only one) width
      </assert>
      <report test="count(./tei:dimension[@type='depth'])>1">
        At most one depth allowed
      </report>
    </rule>

But you're right, that is harder than changing the content model of
<measureGrp>. Of course, because we now have a generic <measureGrp>,
it does mean you wouldn't be able to use it for other things. Who
knows, you might need to describe a medical manuscript with a blood
pressure in the incipit someday!

> A single element <extent>, which admits an attribute to distinguish
> height from width from depth, creates the opportunity to record
> multiple heights but no width, etc. When I specify the page
> measurements in a manuscript description, I require exactly one
> height and exactly one width, and my (custom) schema keeps me from
> doubling one or omitting the other (these are two completely
> independent problems). For what it's worth, I also specify a fixed
> order for the two measurements, not because one order is inherently
> better than another (although I think that is the case), but
> because if you permit either order, you increase the opportunity
> for a user not to notice whether he or she has omitted something
> that should not be omitted.
> 
> The opportunity to omit a specification that in practice must not
> be omitted or to encode twice a specification that in practice must
> be encoded only once arises frequently in the TEI. It is often a
> consequence of the proliferation of 'repeatable or groups'
> (although not only of 'repeatable or groups'), which have become
> even more numerous since we implemented the class system. We may
> decide that the benefits of that system justify the price (reduced
> control and precision) in some cases, but since we want no more
> than one height and one width when we give the dimensions of a
> folio (and the same plus depth for certain other measurements),
> would it not be more reliable to use a model that reduces the
> opportunity to deviate from those requirements?

I hope I'm not babbling. It's *way* past bedtime -- 'night!




More information about the tei-council mailing list