Print

Print


Dear Fotis,
 
A layman's comment to some of your problems (with cc: to the TEI-L,
that's why the layman speaks english):
 
|   1) Incomplete example for the element <hand>
 
This feature was reported before; up to now, the DTD really wants you to
say:
 
<handlist>
<hand id=h hand=h  type='copperplate'  ink='brown'  character='regular'
      ^^^^^^^^^^^
 
     first='yes' resp='das'>
</handList>
 
(You have to give the hand=, since it's required, and you have to give
the ID=, since it's referred to.)
 
 
|   2) Status of legal attribut values vs. suggested values
 
What the manual calls `legal values', are attribute values with an
explicit list of possible values in the `DATA TYPE' slot of the
attribute declaration.  One such is the part= attribute of the <l>
element, which takes only one of Y, N, I, M, F.  My copy of the green
printed P3 Standards, however, says that <add place=..> and <del
rend=..> have the data type `CDATA' and suggests some `suggested
values'.  This seems to make sense to me, too, since the range of
desired values will probably be perceived very differently by different
persons.
 
|   5) How do I encode corrections, which belong together?
 
|   The sentence
|
|     I walked up the bright looking hill.
|
|   has been changed into:
|
|   I walked into the bright looking house.
 
|   Let us assume the change has been made by crossing out >up< and writing
|   >into< above the line and replacing the same way >hill< and >house<.
 
Within the TEI-model, I would suggest two things:
 
a) If you want to point out that the <del> and <add> are *one* act of
revision, not two independent ones which happen to stand side by side,
you can use <app> and <rdg>.  I never became friends with the TEI
proposal of combining <add>/<del> and <app>/<rdg>, as in 18.1.5, on
pp.542-3, but that would be one `official' solution, if you want to keep
<add> and <del> (e.g. because of additional information in the
attributes).  I would rather like to (ab)use <seg> to group the <add>
and <del> together; maybe there are better ways.
 
b) If you count the revision levels with the varseq= attribute, I think
you would get what you want.  Another of my abuses: If the revisions can
really be globally grouped (the pencil-phase and the red-ink-phase, or
something like this), what about bending the meaning of `witness' and
handling them as different witness-IDs?
 
Thus, possible solutions are:
 
I walked
<app type=overlay>
<rdg varseq=1 hand=.. resp=..>up</>
<rdg rdg varseq=2 hand=.. resp=..>into</></>
 the bright looking
<app type=overlay>
<rdg varseq=1 hand=.. resp=..>hill</>
<rdg varseq=2 hand=.. resp=..>house</></>.
 
or (in accordance with 18.1.5, and discordance with me):
 
I walked
<app><rdg varseq=1><del rend=.. type=.. resp=..>up</></>
<rdg varseq =2><add hand=.. place=.. resp=..>into</></></>
 the bright looking
<app><rdg varseq=1><del rend=.. type=.. resp=..>hill</></>
<rdg varseq=2><add hand=.. place=.. resp=..>house</></></>.
 
or (with both):
 
... <rdg wit=base.text> ...
... <rdg wit=red.ink.overlay> ...
 
I think they all do more or less what you want, since the variations are
recorded only where they occur, but coordinated by the varseq=
attributes and/or unique wit= values for the overlay stages.  And you
still have all those attributes of <add> and <del> around.
 
What *I* do not like about the <app>/<del> combination of 18.1.5 is that
it looks to me as though you could select the varseq=1 text only (usual
semantics of <app>) *and* delete `up' and `hill' (usual semantics of
<del>) and still get a valid text, say a reading text of the original
manuscript.  Nobody tells you that you have to insert the content of the
<add> from another <rdg> if you wipe out the content of the <del> in
yours.  In other words, the revisional instructions implied in
<app>/<rdg> and <del>/<add> interfere with each other, at least in my
opinion.
 
My preferred solution would look similar to this:
 
I walked
<seg type=revision><add>up</>
<del>into</></> the bright shining ...
 
You could of course further subclassify the type=revision to
differentiate between several stages of overlay.
 
Hope this helps, at least by firing criticism --
 
        Tobias Rischer
--
....................................................
       (_)                            Tobias Rischer
        "==='      [log in to unmask]
         " "
...still.loving.gnu.................................