I would only disagree with the notion, that the *transcr* module was meant
to be used for _genetic editions_ exclusively. It fits, in my opinion,
perfectly for the diplomatic/topographic/documentary transcription of
facsimiles, where you want to represent the whereabouts of phenomena on the
surface/page, even without marking up handshifts or other genetic
information regarding the sequencees of actions on the manuscript.

Oliver Gasperlin


-----Ursprüngliche Nachricht-----
Von: TEI (Text Encoding Initiative) public discussion list
[mailto:[log in to unmask]] Im Auftrag von Peter Robinson
Gesendet: Mittwoch, 5. Februar 2014 14:15
An: [log in to unmask]
Betreff: Re: [TEI-L] Embedded transcription and text structure

Indeed, as Sebastian points out: this is really a case (yet again) of the
endemic difficulty XML (and its parent, SGML, and any system based on the
OHCO thesis) has with overlapping hierarchies.  

Agreeing twice with Sebastian in a single email: the long-known and
well-established system of using <text> with <pb/>, <cb/> and <lb/> etc,
remains available, and this will allow embedding of <list>, <person>,
<note>, etc, in all the usual places.  And, as James points out, we have
decades of examples of ways of manipulating <pb/> and its friends to create
page-by-page, even line-by-line, views, as you wish.  Our own Textual
Communities project takes this approach, and builds mechanisms for viewing
documents by both hierarchies (page/column/line; text/div/p or l etc) right
into its base.

In my view, one of the problems here is that the wording and presentation of
the current chapter 11 of the Guidelines implies that the system of
<surface>, <zone> etc should be used for transcription of ALL primary source
materials.  Thus its first sentence:

"This chapter defines a module intended for use in the representation of
primary sources, such as manuscripts or other written materials. “

In fact, this system is ideally suited for one rather narrow editorial
circumstance: the transcription of “genetic editions”, typically (almost
exclusively) or modern authorial manuscript materials, where the exact
representation of the writing process in a single document, as a record of
the author’s developing inscription of his work, is so crucial as to trump
every need.  Thus the genesis of the surface/zone system, in the work of the
TEI workgroup on Genetic Editions, chaired by Fotis Iannidis and with Elena
Pierazzo a.o. among its members (see  One might presume
that, encouraged by the Guidelines’ presentation of this system as
appropriate for ALL transcription circumstances, people are using it to
transcribe manuscripts, etc, which are not instances of genetic editions —
hence the repeated requests on this list for a loosening of the content
models for <line> etc. 

So, in contrast to Oliver’s feature request for a loosening of the content
model: I’d agree with the various arguments against this.  I don’t think the
floodgates will open and civilization will drown if we permit <rs> within
model.linePart.  But I do think people will tie themselves up in knots
trying to use a system devised for genetic editions when transcribing (say)
medieval manuscripts.  The problem would be considerably eased, I think, if
the guidelines made it clearer that the system described in Chapter 11 is
really only to be used in the specific circumstance for which it was
devised: for encoding of genetic editions.  In addition, this chapter might
also point out (as it currently does not) that the system of text/pb/lb etc
is efficient and adequate for many transcription situations, and
particularly for projects which wish (as most do) to represent both the
intellectual structure of a text and the disposition of that text in a
document in a single encoding. Seems to me that this might be put into a
feature request.


On 5 Feb 2014, at 06:31, Sebastian Rahtz <[log in to unmask]>

> On 5 Feb 2014, at 12:18, James Cummings <[log in to unmask]>
>> On 05/02/14 11:56, Lou Burnard wrote:
>>> I find it slightly surprising though that no-one has yet proposed
>>> permitting <surface>, <zone> and friends to appear within <text>
>>> as an alternative to  <div>. That would seem a neater way of
>>> having your cake and eating it than any of the proposals so far
>>> made.
>> For some reason that worries me. Perhaps as a muddying of the waters even
further?  It would require changing the content model of zone significantly
to make it useful, wouldn't it?
> I agree, just putting surface and zone into <text> generates a whole slew
more problems than
> it solve. Anyway, we all_know_ there is no clean solution in XML to
> two hierarchies at the same time. 
> the old method of interspersing your <text> with <milestone> elements (or
its specialisations <pb>, <lb> etc)
> hasn’t gone away.
> --
> Sebastian Rahtz      
> Director (Research) of Academic IT
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
> Não sou nada.
> Nunca serei nada.
> Não posso querer ser nada.
> À parte isso, tenho em mim todos os sonhos do mundo.

Peter Robinson
Bateman Professor of English
#311, Arts Building, 9 Campus Drive, University of Saskatchewan
Saskatoon SK S7N 5A5, Canada
ph. (+1) 306 966 5491