Julia Flanders wrote:
> and the to the right, the following role description (which TEI wants me
> to encode as a trailer, though I suggest that <roleDesc> would be better):
Where does this TEI-want come from? <roleDesc> is a permissible child of
<castItem>, and doubtless intentionally so. Of course, if you close
<castItem> immediately after <role>, as in your example, then you are
indeed stuck with <trailer>. But it needn't be so.
> But if I want to represent the lineation of the text (and if lineation
> is a primary reference structure in this situation),
Two big, and logically independent, "if"s. Logically independent even (or
especially) in the not uncommon case where scholars and their editors insist
on the practice of using line numbers as a reference unit in prose texts (or
any text where alineation is not specified in the authorial text itself but
is a by-product of a presentational process.) The result is that any
digital version that needs to preserve the reference system in its entirety
has to jump through one sort of hoop or another, and the outcome is never
easy to encode or render, as well as being more or less unreadable in its
raw state even to XML-clueful humans.
So my first question in such a situation would be: does the *exact*
alineation really need to be preserved, *even in the cast list*? If the
answer here is "yes", then you can't really trust any rendering device to
achieve that unless you spell out where each line break is. And that is
going to make for messy-looking and error-prone encoding of a structure such
as this, whatever way it's approached.
Often, however, exact alineation is not required in all parts of the text.
If it suffices to preserve it only in body text, then the insertion of
<lb/>s, though tedious for encoders, is not all that obtrusive, and doesn't
give rise to the sort of problems related to structured data that the
example poses. If the less stringent requirement of preserving the general
layout and alignment, though not necessarily the exact line break points,
will suffice for the cast list, then another approach becomes possible.
In the general case of text segments that, for semantic as well as
presentational reasons, need to be rendered with a specific set of
horizontal and vertical aligments, the concept that comes to mind is
"table". The snag is that the authors of what is now in P5 called the
Performance Texts chapter decided that cast lists were a special case of a
TEI list, not a TEI table. Which means the existing tagset for encoding a
cast list doesn't offer a crucial facility that tabular markup brings,
namely the ability to give strong hints about vertical and horizontal
arrangement and alignment to a processor, without having to make the
alieneation tail wag the rest of the poor dog into a dizzying blur. Time to
extend, I'd say.