[tei-council] enriching <figure>?

Wed Nov 18 12:34:30 EST 2009

While we're thinking about <figure> (core or no), this is one of the
areas in which we (TCP) and we (TEI) have parted ways most
dramatically. Am I right in supposing that the impoverished
content model of <figure> is due in part to apprehension
lest it prove a foot in the door for a floating div?

We (TCP) do indeed think about <figure> as essentially
a floating div, and our content model for it has moved
it incrementally and awkwardly in that direction. The TEI content model,
OTOH, is oddly patchy. I.e., <figure> may contain <p>, but
not <l>; it may contain <head> but not <trailer> or any of
the other divtop or divbottom tags; and it makes no
provision for any of the many other things that commonly
occur within figures, aside from wrapping them either in
<ab> or in <floatingText>, neither of which is very
satisfying in most cases.

I have considered making SourceForge requests for our most
used (and therefore most useful?) changes, but if these have
been considered and rejected before, or if there is a present
consensus against them, I will not waste either my time or
the Council's in making a case for them.

E.g.:

o <figure> should contain <l> and <lg>.

       Since anything that can be found in prose can also
       be found in verse and often is.

o <figure> should contain <q> (and/or <cit>).

       To accommodate very common mottoes and epigraph-like
       quotations within illustrations, especially
       portraits. (These are allowed now, but only by
       wrapping them in <p> or <ab>.)

o <figure> should contain a tag of attribution, i.e.
   <signed> or <byline> or both,

       To tag such very common things as "drawn by x"
       "engraved by y" "painted by z".

o <figure> should contain <sp>

       In order to tag 'speech bubbles' and similar things.

All of these, to my mind, really do belong to the <figure>
itself, not to a putative <text> containing the <figure>,
nor (in most cases) to a <text> contained within <figure>.
But I would be glad to be corrected or pointed to a
more appropriate way to encode these features.

pfs

--------------------------------------------------------------------
Paul Schaffner | PFSchaffner at umich.edu | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1205
--------------------------------------------------------------------