[tei-council] oversimplification: <measure> isn't measured
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
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.
Need one (and only one) height
Need one (and only one) width
At most one depth allowed
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