> I rather hear from users whether they like my idea of localised
> content models making the m.edit elements characters only but
> retaining their @reg, @sic attributes outside of
> <this-element-contains-a-set-of-alternative-probably-editorial-views>,
> and permitting mixed content but no alternatives attributes
> within the aforementioned element.
Currently, to encode "Allen Renear, PdH", I would be able to use
Allen Renear, <abbr expan="Doctor of Philosophy"><sic corr="PhD">PdH</sic></abbr>
In your world, that wouldn't be allowed, I would have to use
Allen Renear,
<choice found="abbr">
<expan>Doctor of Philosophy</expan>
<abbr>
<choice>
<sic>PdH</sic>
<corr>PhD</corr>
</choice>
</abbr>
</choice>
Hmmm... actually has more expressive power, doesn't it? I mean, if
your source string is "cuoldn't", and you are dead-set against encoding
at the letter level ("c<sic corr='ou'>uo</sic>ld<abbr expan=' not'>n't</abbr>",
for example) you can currently encode only three of the four possible
outcomes.[1] However, with the <choice>[2] mechanism all four can be
recorded:
<choice found="abbr">
<expan>
<choice>
<corr>could not</corr>
<sic>cuold not</sic>
</choice>
</expan>
<abbr>
<choice>
<corr>couldn't</corr>
<sic>cuoldn't</sic>
</choice>
</abbr>
</choice>
On the other hand, I'd say it's still necessary to permit the
<soCalled>global inclusion</soCalled> elements[4] as permissible
children of <sic corr=>, <corr sic=>, <orig reg=>, et al. Otherwise,
how would you record the line break in
Today a surprise hit: a reference work, "The TEI Giude-
lines" made it to the NY Times bestseller list. This is
only the ...
I would want to use
... <sic corr="Guidelines">Giude­<lb/>lines</sic> ...
on the theory that whenever my style-sheet is spitting out the closest
I can to the original source, I would want the <sic> value, the soft
hyphen, and the line-break; and that when my style-sheet is spitting
out a version for modern readers uninterested in the details of the
particular source edition, I would want the corr= value, and would
not want soft hyphens nor line-breaks anyway.
On the other hand, if I wanted to be able to correct the spelling
while retaining original lineation, I'd have to resort to <choice>
anyway, eh?
Notes
-----
[1] The four possible combinations are
* expanded, error corrected = could not
* expanded, error not corrected = cuold not
* contracted, error corrected = couldn't
* contracted, error not corrected = couldn't
and since it's hard to see why anyone would care about the second
one, I would normally encode this as
<abbr expan="could not"><sic corr="couldn't">cuoldn't</sic></abbr>
from which the other outcomes can be extracted, but "cuold not"
could not.
[2] The use of the value "choice" as the GI for the
alt-or-choice-or-choose-or-crossroads-or-variation-or-version
element does not signify endorsement by the TEI, the WWP, or even
the author, his heirs, or his lawyers. It's just an example.
[3] Note that the found= attribute (or some other mechanism) is
necessary to record which of the alternatives (<abbr> or <expan>)
was that which was found in the source document. It is redundant
in both the case of <sic> & <corr> (after all, that's what "sic"
means) and of <orig> & <reg> (after all, that's what "orig"
means). However, with <abbr> & <expan>, there is no way a priori
to know which version occurred in the source.
[4] I.e., the m.Incl class, whose members are currently
<addSpan>, <alt>, <altGrp>, <anchor>, <cb>, <certainty>,
<delSpan>, <fLib>, <fs>, <fsLib>, <fvLib>, <fw>, <gap>,
<index>, <interp>, <interpGrp>, <join>, <joinGrp>, <lb>,
<link>, <linkGrp>, <milestone>, <pb>, <respons>, <span>,
<spanGrp>, and <timeline>.
|