Text Encoding Initiative

A good and useful summary. Thanks.
-dan

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
>only.
>
>--------------
>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 twins.
>-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 become?
>-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 useful?
>-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 specification.
>-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 http://users.ox.ac.uk/~jamesc/cfp.html
>
>
>-------------------------------------------------------
>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.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Tei-choice mailing list
>Tei-choice@...
>https://lists.sourceforge.net/lists/listinfo/tei-choice
>  
>

-- 
Daniel Paul O'Donnell, PhD
Associate Professor of English
University of Lethbridge
Lethbridge AB T1K 3M4
Tel. (403) 329-2377
Fax. (403) 382-7191
E-mail <daniel.odonnell@...>
Home Page <http://people.uleth.ca/~daniel.odonnell/>

> I've done a (very quick) summary/minutes of the discussion 
> we've had so far in case it is helpful ...

Thank you, James. Unless there's another volunteer, I hope to take a
stab at writing up one suggested mechanism (the third, <z> wrapper
one) in the formal ODD format for P5 for discussion here within a
week or so. I am currently planning to use the name "zzz" for the
wrapper element name so that whatever we decide can be ued with a
simple find-and-replace.

On Sun, 15 Aug 2004, Syd Bauman wrote:

> > I've done a (very quick) summary/minutes of the discussion 
> > we've had so far in case it is helpful ...
> 
> Thank you, James. Unless there's another volunteer, I hope to take a
> stab at writing up one suggested mechanism (the third, <z> wrapper
> one) in the formal ODD format for P5 for discussion here within a
> week or so. I am currently planning to use the name "zzz" for the
> wrapper element name so that whatever we decide can be ued with a
> simple find-and-replace.


In going through the old posts, as much as I disliked the 
name 'choice', I could not a) think of a better name that 
didn't sound awkward to me and b) came to think of it being 
named that even when reading the posts suggesting something 
else.  As a result, for me, everything sounds _wrong_ in 
comparison. (So I won't be a helpful judge on what it should 
be called.)

-James

---
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 http://users.ox.ac.uk/~jamesc/cfp.html

Quoting "James.Cummings@..." <James.Cummings@...>:

> In going through the old posts, as much as I disliked the
> name 'choice', I could not a) think of a better name that
> didn't sound awkward to me and b) came to think of it being
> named that even when reading the posts suggesting something
> else.  As a result, for me, everything sounds _wrong_ in
> comparison. (So I won't be a helpful judge on what it should
> be called.)

I concur with this. Despite writing one of the early rants against <choice> as a
name, <choice> has now lodged itself in my brain.

Stuart

A very preliminary draft of a new choice element called <zzz> is now
available for this group's review. It is known to be incomplete in a
few ways: 

* The sic= attribute has not been removed from <corr>, the orig= from
  <reg>, etc, yet.

* There is no section to explain the use of <zzz> with generic (i.e.,
  <seg> children), yet.

* The section on <abbr> & <expan> is not included in this draft.

* The specification of the <zzz> element content makes use of RelaxNG
  features that the ODD system is not yet ready to handle. It may
  well be the case that ODD cannot handle these features by the time
  P5 goes to press (perhaps not even ever, although I hope not), in
  which case we'll have to rework it a bit.

Not to mention whatever shortcomings this group finds.


There are several files of interest.

HTML version:
http://www.tei-c.org/Drafts/Choice/FASC-coed-Guidelines/index.html
        and click on "1 Core Tags", or go straight to
http://www.tei-c.org/Drafts/Choice/FASC-coed-Guidelines/index-div1-id708264.html

XML versions:
http://www.tei-c.org/Drafts/Choice/FASC-coed.xml and
http://www.tei-c.org/Drafts/Choice/FASC-coed-lite.xml

PDF version:
http://www.tei-c.org/Drafts/Choice/FASC-coed.pdf

A view of TEI schema with <zzz> included:
http://www.tei-c.org/Drafts/Choice/TSTtei.compiled.rnc
http://www.tei-c.org/Drafts/Choice/TSTtei.compiled.rng

As you read please realize that "1.1" is a placeholder for whatever
section number this becomes (currently it is "6.5").

Thank you very much, Syd!

Syd Bauman skrev  22.08.2004 09:07:

> A very preliminary draft of a new choice element called <zzz> is now
> available for this group's review. It is known to be incomplete in a
> few ways: 
> 
> * The sic= attribute has not been removed from <corr>, the orig= from
>   <reg>, etc, yet.

Do we believe that it should?

> 
> * There is no section to explain the use of <zzz> with generic (i.e.,
>   <seg> children), yet.
> 
> * The section on <abbr> & <expan> is not included in this draft.

Why not - is this intentionally?
> 
> * The specification of the <zzz> element content makes use of RelaxNG
>   features that the ODD system is not yet ready to handle. It may
>   well be the case that ODD cannot handle these features by the time
>   P5 goes to press (perhaps not even ever, although I hope not), in
>   which case we'll have to rework it a bit.

But there will still be a DTD-version, or won't there?

Espen

> > * The sic= attribute has not been removed from <corr>, the orig= from
> >   <reg>, etc, yet.
> Do we believe that it should?

I think so. (Both that we believe that it should be removed, and that
it should be removed :-) The basic idea is to permit <sic> in running
prose to indicate that there's an error, but to use
<zzz><sic>hte</sic><corr>the</corr></zzz> to indicate both an error
and its correction. (Reduces the number of places a correction, e.g.,
could be.)


> > * The section on <abbr> & <expan> is not included in this draft.
> Why not - is this intentionally?

Yes, it's intentional, but also only temporary. The main thing is
simply that <abbr> and <expan> are covered in a different section,
not in 6.5. If things go well, I'll have this part done by sometime
tomorrow.


> > * The specification of the <zzz> element content makes use of RelaxNG
> >   features that the ODD system is not yet ready to handle. It may
> >   well be the case that ODD cannot handle these features by the time
> >   P5 goes to press (perhaps not even ever, although I hope not), in
> >   which case we'll have to rework it a bit.
> But there will still be a DTD-version, or won't there?

Of P5? Yes, we are currently planning to provide DTDs for P5
validation. The fact that a DTD cannot enforce these constraints
where RelaxNG doesn't really bother me. Given their different
capabilities, users are going to have to get used to the idea that
different schema languages validate different subsets of the TEI
constraints on doucments. However, if ODD can't describe it, then we
have a problem on the source upkeep and maintenance end, not just the
schema generation end.

I've now completed the first three of the four items I left undone in
the previous draft. The last one (using RelaxNG constructs that ODD
doesn't know how to handle), which is a biggie, I have not touched,
since I want feedback from this group on what should be done and we
need to know from the Meta workgroup what can be done.

New version of draft is on the web. At Lou's suggestion it is now
properly incorporated into the chapter on core tags. One small
section, on using the choice mechanism with generic elements (<seg>)
is in the chapter on segmentation.

So, there are two sections of Core Tags and two paragraphs of
Segmentation to read, review, and comment on:

CO.4
http://www.tei-c.org/Drafts/Choice/FASC-co-Guidelines/CO.html#COED
http://www.tei-c.org/Drafts/Choice/FASC-co.pdf, section "1.4", p. 16
http://www.tei-c.org/Drafts/Choice/FASC-co.xml#COED

CO.5.5
http://www.tei-c.org/Drafts/Choice/FASC-co-Guidelines/CO.html#CONA
http://www.tei-c.org/Drafts/Choice/FASC-co.pdf, section "1.5.5", p. 35
http://www.tei-c.org/Drafts/Choice/FASC-co.xml#CONAAB

SA.2 (easiest way to find right spot is to search for "zzz")
http://www.tei-c.org/Drafts/Choice/FASC-sa-Guidelines/SA.html#SASE
http://www.tei-c.org/Drafts/Choice/FASC-sa.pdf, top of p. 11
http://www.tei-c.org/Drafts/Choice/FASC-sa.xml#SASE

To play with the current declaration of <zzz>, use
http://www.tei-c.org/Drafts/Choice/TSTtei.compiled.rnc
http://www.tei-c.org/Drafts/Choice/TSTtei.compiled.rng

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 to.

Hope all is well.

Edward

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
> only.
> 
> --------------
> 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 twins.
> -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 become?
> -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 useful?
> -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 specification.
> -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 http://users.ox.ac.uk/~jamesc/cfp.html
> 
> 
> -------------------------------------------------------
> 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.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Tei-choice mailing list
> Tei-choice@...
> https://lists.sourceforge.net/lists/listinfo/tei-choice
> 

-- 

================
Edward Vanhoutte
Co-ordinator
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
edward.vanhoutte@...
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

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.

Best,

Edward

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 
> to.
> 
> Hope all is well.
> 
> Edward
> 
> 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
>> only.
>>
>> --------------
>> 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 
>> twins.
>> -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 
>> become?
>> -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 
>> useful?
>> -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 
>> specification.
>> -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 
>> http://users.ox.ac.uk/~jamesc/cfp.html
>>
>>
>> -------------------------------------------------------
>> 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.
>> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>> _______________________________________________
>> Tei-choice mailing list
>> Tei-choice@...
>> https://lists.sourceforge.net/lists/listinfo/tei-choice
>>
> 

-- 

================
Edward Vanhoutte
Co-ordinator
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
edward.vanhoutte@...
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm