The early hours of Mondays ara always dangerous for sending unintended
mails to lists. This one was meant for James personally, but I'm sure no
one would protest my question. (after all it is about a TEI choice).
Apologies for this.
Edward Vanhoutte wrote:
> Dear James,
> Would it be ok if I, as a member of the TEI nominations committee, put
> your name down for the upcoming elections for the Council in Baltimore?
> I'm sure your expertise and eperience with texts and the OTA will be of
> much us to the TEI-C.
> I won't be there in Baltimore, cause I don't have the fundings to go.
> Apart from the fact that the USA is still not my favourite country to go
> Hope all is well.
> James Cummings wrote:
>> Dear All,
>> I've done a (very quick) summary/minutes of the discussion we've had
>> so far in case it is helpful for someone wanting to make any more
>> suggestions, and stimulating discussion. I do apologise for leaving
>> out anyone's ideas or misattribution or misrepresentation of them. It
>> is how I saw the discussion
>> TEI Choice: Summary of some of the points discussed so far.
>> - mailing list arranged to produce straw draft proposal to knock down
>> but stimulate discussion
>> - Hugh Cayless questioned whether <choice> was appropriate
>> semantically for some of the operations under consideration.
>> - but for instances like <corr>/<sic> the sequence model was seen as
>> less robust than <choice>.
>> -Lou Burnard noted that <choice> element implies that any single child
>> could replace it at this point in the text, and nothing more.
>> -Odd Haugen noted the Menota project's use of a redefined <w> in much
>> the same way as the proposed <choice>
>> -Daniel O'Donnell wondered how this <choice> was going to be different
>> from orig/reg, especially with respect to nesting. He also noted that
>> TEI already has a very similar data model in the critical apparatus
>> tags app/rdg.
>> -Daniel O'Donnell considered the question of whether the generality
>> (one-size-fits-all) of <choice> might be a problem, and that if it
>> really is a structure, perhaps we should be considering implementing
>> instances of this e.g. <correction>, <abbreviation>, etc.
>> -Lou confirmed that <app> is a specialised version of the proposed
>> <choice> but with textual criticism specialities built in.
>> -It was agreed that although general <choice> shouldn't be used for
>> cases like <quote>/<cit> or <gloss>/<term> which are not choices but
>> -Daniel O'Donnell asked how specified the children of choice should
>> be. <app>/<rdg>/<rdggrp> are only allowed inside <choice>, should
>> elements like <corr> that will be intended to be used inside choice be
>> forced to only appear here? How mandatory will the choice mechanism
>> -Lou Burnard believed it would be unreasonable to not continue to
>> allow <corr>/<sic>/etc. outside of choice, but thought removing their
>> attributes (@corr/@sic) would encourage people into using choice where
>> a choice was clearly being encoded.
>> -Daniel O'Donnell wondered about transposition and movement of words
>> and how <choice> might affect that.
>> -Lou Burnard believed these could be dealt with outside of <choice>,
>> but Daniel felt they were fundamental and poorly handled in both print
>> and digital form.
>> -Hugh Cayless was concerned about situations where abbreviated and
>> expanded forms were not equivalent alternatives and that <choice>
>> might be misrepresenting this. Daniel was less sure there was a
>> fundamental distinction between contracted and other symbolic
>> abbreviations. -Daniel O'Donnell questioned the taxonomy of <choice>
>> as misleading and implying that a choice must be made (and as similar
>> to the procedural <xsl:choose>), and later reminded Hugh that
>> expansions are not modifications of abbreviations but parallel forms
>> -Patrick Sahle suggested the choice-concept's strength came from its
>> ability to encode alternatives on a single portion of text, and it
>> should be named to reflect that.
>> -Hugh Cayless wondered if <choice> indicates a temporary shift from a
>> single text stream to multiple parallel ones, what happens about
>> mark-up and choices within this?
>> -Daniel O'Donnell suggested one way to deal with this is specified
>> choice-mechanism tags: if <abbr> had <short> and <long> children, or
>> <corr> had <corrected> and <original> children. Suggesting a
>> multiplicity of choice-mechanism tags that could work in the same way
>> as the proposed <choice> but for specified instances.
>> -Martin Holmes suggested <branch> or <fork> for a generalised name,
>> Patrick disliked the tree-model implication rather than that of
>> concurrent perspectives.
>> -James Cummings asked if <choice> will be able to be infinitely nested
>> in the same manner as <app>/<rdg> structures. Daniel believed that
>> they should and that this will be extremely powerful in complex
>> situations. Lou also had no problem with nesting per se. James
>> wondered in what other situations nesting <choice> elements would be
>> -Patrick Sahle summarised that we were talking about two things a)
>> remodelling established concepts like <corr> and b) creating a new
>> general element <choice>
>> -Lou added that the choice we were making was between:
>> 1)for every existing janus tag <x> with attribute y, define a new
>> wrapper <xy> with content <x>, <y>
>> 2)define a generic tag <z> with content such as ( (x?,y?) | (a?,b?) |
>> (c?,d?) )... to replace all existing janus tags x, a, c ...
>> 3)define a very general tag <z> with no particular restriction on its
>> content, but a clear semantics that says "you can replace me by one
>> and only one of my children here"
>> -Daniel suggested a preference for 1. and 3. (with 3. being similar to
>> the general <seg>) and made the two suggestions that: 1)define a very
>> general <z> tag with no particular restriction on its content by a
>> clear semantics that says "I indicate the existence of simultaneous
>> multiple possibilities for a specific point in the textual stream;
>> these parallel possibilities are encoded on my children"
>> 2)define specific wrappers for special cases in which this textual
>> situation regularly occurs: the existing janus tags (in the strict
>> sense); indicate that app is another example; look for others in the
>> -Hugh Cayless suggested a definition along the lines of: "<choice> is
>> a general element used to indicate synchrony. Its children are
>> conceptually speaking either parallel or mutually exclusive. More
>> specific elements exist for specific types of synchrony. These include
>> the <app> and <rdggrp> elements" but would like to see <abbr> and
>> <corr> added as choice-mechanism elements themselves rather than
>> children of choice. Daniel agreed in principle but disliked the idea
>> of synchrony in all cases. He felt the difference of choice from
>> apparatus readings which are mutually exclusive is that <choice> seems
>> to me to be that it's not presenting parallel readings by more than
>> one person, just parallel observations such as a perceived error and
>> its suggested correction.
>> -Daniel O'Donnell felt that <choice> should be kept as a general
>> element whose children must be understood as occurring at the exact
>> same point. But that <choice> would be reserved, like <seg> as a
>> generic marker for other places that the TEI hasn't thought of in
>> which children are understood as occupying the same point in the
>> textual stream.
>> -Hugh argued that an abbreviation and expansion aren't occupying the
>> same space and that we shouldn't make <abbr> a choice-mechanism as it
>> can be used when there is no fundamental choice, simply the marking of
>> an abbreviation. Following on from Daniel's suggestions he felt that
>> <abbreviation> might be a new element as a specific wrapper, but
>> wondered if it was the old janus tags <abbr>/<expan> which should be
>> used inside the wrapper. He also wondered whether you could then only
>> have a single child to <abbreviation> if no choice was being
>> indicated. James suggested the retention of the existing names as less
>> confusing and pointed out that an <abbreviation> wrapper would only be
>> used if a choice-mechanism was being invoked, otherwise using <abbr>
>> outside of <abbreviation> would make sense.
>> -James Cummings wondered if there should be a mechanism for indicating
>> a default choice, as over an entire document the default might be X
>> but inside a particular <choice> you might want to indicate it was
>> different in this one instance. Daniel thought it might be a good
>> idea for a default attribute, but wondered if this became a display
>> issue. Patrick thought it should be left to the processing. Daniel
>> felt an attribute would be useful in this processing. Hugh felt there
>> was no reason to indicate a default reading and wondered how people
>> did it currently. James expressed a preference for the general
>> <choice> over the possible proliferation of other wrappers.
>> -Patrick Sahle suggested <concurrent> or <concurrentView> for the
>> general choice element
>> -Many other suggestions and examples were discussed in wrestling with
>> these issues, much has been left out here.
>> Dr James Cummings, Oxford Text Archive, University of Oxford
>> James dot Cummings at oucs dot ox dot ac dot uk CALL FOR PAPERS:
>> Digital Medievalism (Kalamazoo) and Early Drama (Leeds) see
>> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>> Tei-choice mailing list
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Reviews Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49