[tei-council] choice, etc.--finally.

[Daniel O'Donnell]

This is the piece I tried to send several times to council last week. It
was written as a discussion piece. 




-----Original Message-----
From: O'Donnell, Dan
Sent: Wed 01/08/2007 16:28
To: tei-council at lists.village.virginia.edu
Subject: I'm not sure this made it on the list this morning


Hi all,

I sent this early this morning, and it was in my "sent" box, but I never
saw a copy unlike what usually happens. If it didn't make it out, sorry
for the delay; if it did, I've added a new small postscript:

Hi all,

Sorry for the delay in getting this out. With my jetlag, I just fell
asleep last night and then only woke up long enough for a planning call
for tomorrow's meeting. On the other hand, jetlag also means its a snap
getting up at 5.

I was asked by Christian to look into combining my proposals for
rearranging the model.pPartEdit and children classes (choice,
abbr/expan, and transcription elements; see: http://tinyurl.com/39qoua)
with Matthew's editorial proposals (regarding edInt, subst., and the
like: see http://www.tei-c.org/Drafts/edInt.xml). There has already been
some discussion of both.

==The class models==

As far as I am aware there have been no objections to the reorganisation
and modifications I proposed, which involved

* Some changes to the description of choice's element description to
reflect the fact that its usage currently concerns entirely grouping
transcriptional and editorial alternate states/alternative rather than
alternate states in general.
* making various additions and changes to the membership of
model.pPartEdit and model.choiceLike and (since the new model.choiceLike
coincides exactly with the final content of model.pPartEditorial and
model.pPartTranscriptional), getting rid of these classes
* creating a class model.restoreLike to allow us to built a more
specific content model for restore
* moving app to model.listLike

==Matthew's Proposals==

Mathew's proposals centred around two elements, <edInt> and <subst>,
both of which are arguably semantically specific versions of <choice>.
<edInt> is to be used to group children like <sic> and <corr> when these
children refer to interventions in the abstract editorial text rather
than physical changes in a witness. This, if an editor notices that a
text has "brian" instead of "brain" <edInt> would be used:

 <p>My <edInt type="emmend" resp="#MJD"
cert="high"><sic>brian</sic><corr>brain</corr></edInt> hurts.</p>

But if a scribe had noticed it, <choice> would be preferred:

 <p>My <choice><sic hand="#scribeA">brian</sic><corr
hand="#scribeB">brain</corr></choice> hurts.</p>

Where <edInt> is not like <choice>, however, is that the proposal allows
its content model to include text:

 <edInt type="supply" reason="omitted" resp="#MJD" cert="high">t</edInt>

<subst> is to be used when a scribal change in a witness is to be seen
as part of a single act: e.g. if a correction is clearly the result of a
scribe catching an error and correcting it him/herself:

 <p>my brain <subst hand="#scribeA"><del
rend="overstrike">burns</del><add
place="margin">hurts</add></subst>.</p>

If on the other hand the encoder doesn't want to make this assertion (or
if the add/del are not in the same hand or otherwise clearly not part of
a single act), choice would again be used:

 <p>my brain <choice><del rend="overstrike"
hand="#scribeA">burns</del><add place="margin"
hand="#scribeB">hurts</add></choice>.</p>

Integrating these proposals into mine would be a relatively simple
matter if we did not allow <edInt> to contain text directly. Their
allowed children are all members of the revised model.choicePart content
model and, as I argue above, they are both really semantic refinements
of <choice>. Basically all that would be required is creating a
model.choiceLike to include them and the generic case <choice> and
substituting this wherever <choice> would otherwise be used (in my
proposal in model.pPartEdit; currently in model.pPartEditorial).

The idea of a model.choiceLike class appeals to me, because I think
<choice> is going to be a productive element once people get used to it.
However, I am a bit wary at this point of proposing two semantic
specialisations this early in its development: why provide elements for
the equivalent of choice at type="editorial" and choice at type="substitution"
but not choice at type="fire damage" or choice at type="scribal"? So my
recommendation is that for P5 we don't add a model.choiceLike class and
leave out <edInt> and <subst>, encouraging people instead to use @type
or @reason to cover semantic attributes of the grouping. If we decide to
put one or both in anyway, I'd recommend making them real
specialisations of choice and disallowing textual content in either.

Regardless, I think that Matthew's work shows we need to be prepared for
people to discover new uses for the generic element: for this reason
I've changed my mind on including a generic <option> element to replace
<seg> that is currently in the content model: I think we should include
to to encourage this kind of experimentation with choice-like syntax.

P.S. Since writing this I've though a lot about the desire to indicate
semantically the difference between editorial and primary source
corrections--something I've long felt myself. Another option might be to
have <emend> as a parallel to <corr>, for example (<sic> is already
editorial). The problem with this is that really we'd need editorial
parallels to the other actions: del and restore at the least. On the
other hand, I suppose edAdd, edDel, and edRestore as syntactic sugar for
add at type="editorial" etc. would not be the end of the world. It would
solve my objections to building a few more specific versions of choice.