[tei-council] Re: choice

[Lou Burnard]

Christian Wittern wrote:


> Which brings me to the question:  What is the status of <choice>?
> 

A good question!  Here's my attempt at an answer. Anyone interested in 
the history of the discussion can of course read it by going to the 
tei-choice list archive, readily accessible from the tei sourceforge 
site (go to http://sourceforge.net/mailarchive/forum.php?forum_id=41178) 
The most recent posting was a useful summary of various possible 
approaches to an implementation which Syd produced in September. For 
those who don't want to wade through the sourceforge archive, I've also 
placed this on the TEI website at 
http://www.tei-c.org/Drafts/Choice/summary.txt

Since that discussion, I've started (but not finished) some tidying up 
of the text of the part of P5 where <choice> is first introduced: there 
is an XML version of this at 
http://www.tei-c.org/Drafts/Choice/choice.xml, but it has not yet been 
integrated into the main P5 source tree. The tidying up  led me to some 
further rethinking of what we should be recommending for this element, 
on which I would appreciate comments from the Council.

The main issue remains: what should the content model of <choice> be.
We started with a fairly complex structure designed to mimic only the 
functionality of the janus-tags <corr>, <sic> etc. I then suggested it 
might be good to generalize this to support other, more possible kinds 
of parallel readings, e.g. a passage might be marked as unclear, with 
both a regularized form, and a corrected form, and that we could do this 
with a content model using two classes, rather than two explicit 
elements. I proposed originally a class "tei.sic" for readings that 
seemed to be based on what the text "says", and another class "tei.corr" 
for what the text "ought to say", with the suggestion that the model 
might be (tei.sic, tei.corr+)

Thinking about this again I would like to propose that the model should 
be loosened still further, to something like (tei.choosable, 
tei.choosable+). There are definitely some elements (<seg> as John 
Smith's group have proposed) which would need to be members of both 
tei.sic and tei.corr, which would lead to a non-deterministic content 
model if we adopted my earlier suggestion.  More to the point, I am 
increasingly uncomfortable with the distinction between what the text 
"says" what it "ought to say".

So, my view now (which I will also post to the TEI-choice list for 
comment) is that we ought to allow for 2 or more elements from the 
"tei.choosable" class inside <choice> and leave it at that. The members 
of that class are up for grabs, but my current preferred list would be
<sic>, <corr>, <reg>, <seg>, and <unclear> only. Oh, and <choice>, of 
course.

Syd made the interesting comment that it was hard to distinguish (in a 
non-janus world) between <orig> and <sic>, which the more I think about 
it, the more I agree with, which is why <orig> is not on the list above. 
I see less and less use for this element.

I haven't included <add> and <del> in the list, because I cannot think 
of any real situation in which they would be "choosable" -- either there 
is an addition/deletion in the text or there isn't. If you wanted to 
indicate that one way of interpreting e.g. an addition was by some 
regularization or other, then I think you should wrap the addition 
within a sic, like this
<choice>
  <sic>1<add>st</add></sic>
  <reg>first</reg>
</choice>

For a given application, of course, people may well want to constrain 
the choosable elements, or add others to them. But the basic 
out-of-the-box element, I suggest, need not be any more complex than this.