Received: from UKACRL.BITNET by UICVM (Mailer R2.03B) with BSMTP id 5292; Wed,
 28 Feb 90 12:35:58 CST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 3051; Wed,
 28 Feb 90 18:29:19 GMT
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2039; Wed, 28
          Feb 90 18:29:16 GM
Via:      UK.AC.OX.VAX; 28 FEB 90 17:57:24 GMT
Date:     Wed, 28 Feb 90  17:42 GMT
From:     TEI@VAX.OXFORD.AC.UK
To:       U35395@UICVM
 
From:	VAX::TEI          28-FEB-1990 09:17:30.96
To:	LOU
CC:	TEI
Subj:
 
Robin Cover
28-Feb-90
Synthesis & Revision of W16 (Cover), W18 (Ott) and comments by Peter
Robinson
 
SUMMARY OF PROPOSAL/PROBLEMS FOR TEXTUAL VARIATION AND CRITICAL APPARATUS
 
1. MAJOR GOALS
     *provide encoding for critical apparatus in critical editions
      (the typographic conventions)
     *provide model for encoding textual variation (database model)
 
2. MAJOR OUTSTANDING PROBLEMS
     *referencing system
     *syntax rules or SGML representation for pattern matching
      (specification of discontinuous sub-elements)
 
3. SKELETON PROPOSAL - with focus on encoding for the critical apparatus
 
<apparatus-entry type=app-crit-level)
 
   *element following the (first) word which is of text critical interest
   *if several textual problems are attested in the same (overlapping)
      region, treat those with greatest span first, each w/ <apparatus-entry>
   *type attribute assumes that app-crit levels are differentiated by focus
      on different lemmata; if not, redundant specification of lemma can
      be overcome by setting an app-crit-level attribute on the <variant>
   *<apparatus-entry> has one <lemma> and one or more <variants>
 
<lemma> .....</>  contains
 
<lemma-locus>  as-yet unsolved mechanism for referencing the locus in
    terms of offsets (including discontinuous segments) from an external
    locus; mechanism should be derivable from hardcopy version of the text
 
<lemma-locus-detail> optional, data on cross-referencing, etc.
 
<lemma-reading>  the content of the lemma; if not just PCDATA, needs
    mechanism for encoding boundaries, excluded sub-elements, etc.
    (typical app crits use [xxx], and ... and other conventions
 
<lemma-detail>  all other data, as structured as necessary/desirable,
    about the language, script, linguistic annotations, evaluation
    by editor
 
<variant>  ....</>  this is the top-level normalization with the lemma
    each variant has...
 
<variant-reading>  the text or content of the alternative reading,
    normalized to the level of the lemma
 
<witness>  each <variant-reading> has one or more witnesses
 
<witness-name> required for each witness; the witnesses may be mixed
    in type: a single manuscript, manuscript-family, edition, tradition
    (e.g., "Old Greek" or "Old Latin" for a biblical text, where the
     reading must be inferred from evidence not necessarily found in an
     edition)
 
<witness-locus>  same problems as with <lemma-locus>
<witness-locus-detail>   optional
<witness-reading> optional, but usually desirable if different than
     normalized form given in <variant-reading>
<witness-detail>  all other relevant information about the <witness-reading>,
    language, script, linguistic annotations, etc.
 
<variant-reading-detail>  optional, other annotations on the <variant>
   as a whole