Print

Print


On Thu, 2006-09-03 at 12:12 -0500, Francois Lachance wrote:
> Some spice: two items:
> 
> One.
> 
> I want to return to the question of the children of <choice>.
> 
> What is not evident from the alphabetical listing of its members:
> 
> abbr corr expan orig reg seg sic unclear
> 
> is the sets of pairings:
> 
> abbr expan
> corr sic
> orig reg
> 
> Can someone please explain how <seg> came to be included in content model
> of <choice>? Also <unclear>?

The origin of choice was to get rid of the socalled janus tags,
abbr/expan, corr/sic, orig/reg. Or more correctly provide a mechanism
for grouping them explicitly and keeping textual content out of
attributes. Originally, for example, abbr/expan were paired thusly:
<abbr expan="um">&umacr;</abbr> (which is fine) and <expan
abbr="&umacr;">um</expan> (which is not, since attribute values are not
parsed).

Once we started thinking about it, though, it became clear that what we
were really talking about was the expression of simultaneity--i.e. the
idea that these pairing are really expressing moments in which you can
understand and markup the text in two or more different ways at the same
time, and that the situations in which one might want to do that were
far broader. As I kept stressing, for example, app is also a kind of
specialised choice.

I don't remember what the janus pair of unclear would be, but you can
certainly see that it might mark a point of simultaneous markup... maybe
<unclear><supplied>?

Anyway, as I remember the original discussion we were quite catholic
about the content of choice, which I think is the right approach, as I
think it is actually a generic marker for simultaneity similar to seg
and ab, rather than w or p. It should also have type for that reason, in
my view. And I think ultimately there should be more specialised
elements for specific types of choice: e.g. abbreviation,
regularisation, emendation, collation, transliteration, are all
specific, traditional types of choices that have their own content
models. We're not there for two reasons: legacy tagging (we already have
an element call abbr that refers not to the state of
abbreviation/expansion, but to the short form, for example); and because
I don't think we've got a handle on how radical an element choice
actually is: it is a real digital encoding tag, as opposed to a print
encoding tag: we use it to express something we can't easily show in
print.

-d




> 
> 
> Two.
> 
> I note in passing that <c> can be a child of the <choice> children and
> come to my second question. It relates to a statement by Michael...
> <snip>
> would be using the type attribute's value, not so much to assign a
> taxonomic category as to express a content restraint. And I would tend to
> regard that as a precursor of attribute abuse, if not actually  already
> abusive in itself,
> <snip/>
> 
> In my opinion such a practice is not yet abusive especially if the
> practice is documented in the TEI header. One could of course extend the
> tag set to create attributes which indicate the restraints on the content
> of the element to which they attributes. Interestingly <seg> has the
> possibility of taking a "subtype" attribute. It is conceivable that a
> project implement taxonic description on the "type" attribute and mark
> indications of content restraint on the "subtype".
-- 
Daniel Paul O'Donnell, PhD
Acting Chair and Associate Professor of English
Director, Digital Medievalist Project
<http://www.digitalmedievalist.org/>
University of Lethbridge
Lethbridge AB T1K 3M4
Canada

Vox: +1 (403) 329-2378/-2377
Fax: +1 (403) 382-7191