[MB]
>> If you are content for readers to have access to the kind
>> of information that would be provided in a printed critical
>> edition, there may be no need for the relationships you are
>> talking about to be encoded in markup at all (rather than
>> simply described in plain text, doubtless making use of
>> whatever textual reference system a print edition would
>> deploy). But if you want more, you need to decide what that
>> "more" is, and how much of it you want, before committing
>> to a markup scheme.

[YC]
> A scholar might want to have a global view of correspondances
> between  the different recensions of a text, and I was
> wondering how the  necessary information could be stored to allow this.

In other words, you want to exploit the ability of electronic documents to
construct and display various views of a text (rather than just offering
discursive and/or diagrammatic accounts of the relationships behind such
views, of a kind that print editions are largely confined to). Good.

But that means you really do have to think in some detail about how you
envisage such multiple views being built and presented, because until you
have some fairly clear ideas on that point, you won't be able to decide
between the many and various ways of encoding them. The Guidelines won't
help much with actually finalising that decision, though they will furnish
the markup side of the information you need to make it. But you also need
information and understanding about what is currently feasible by way of
processing and delivery (and maybe also some sense of what may become
feasible in the short to medium term), and you won't find that in the
Guidelines.

Those Guidelines are, as a matter of policy, largely agnostic about
processing and delivery. In a world where essential scholarly requirements,
such as the TEI is charged to address, remain constant while the
possibilities of processing grow and change apace, any other policy would
court rapid obsolescence. But that does mean that you will need to explore
beyond the Guidelines if you want to make appropriate decisions about how to
apply them for your purposes.

It's a widely-held maxim in the electronic texts world that processing ought
not to determine markup. The principle behind that maxim is sound and worth
defending, but in practice I think that processing can and often should be
allowed to shape the final decision about which of several markup
possibilities to choose. I would suggest you should draw up a list of the
sort of views of your text you wish to offer, perhaps looking at some recent
digital editions of other texts in various fields of scholarship and noting
features you would like to adopt or develop, and then investigate the
processing necessary to produce those views. Your decisions about which of
the various markup possibilities to adopt among those offered in the
Guidelines could then be informed by what would best achieve the
presentation you desire.

Your specific question I think illustrates why the approach I'm suggesting
is desirable, because it is really only immediately relevant in the specific
form you pose it if you have already decided to stick with what is
essentially a digital transcription of a conventional print edition. Where
there are multiple witnesses (or where there are only two, but their
readings co-incide over lengthy stretches, making parallel printing
unacceptable) a scholarly print edition can do no other but print in extenso
an editorial body text and annotate it with an apparatus noting variant
readings, emendations etc. etc.  This can of course be mirrored in markup by
putting the editorial text into <lg>s and associating <app> elements with
those <lg>s. Possibly in conjunction with <note>s, those <app>s can convey
information about presence or absence of material, or divergences in
sequence etc as well as detailed textual variants. But they needn't expose
that information in processable form, and more than the print edition on
which such a transcription is modelled does.

However, there are other approaches, which would mean that the information
you here envisage being placed in <app>s associated with the body text (and
maybe rendered at the foot or in the margins of the digital "page") would be
encoded differently. Towards the other end of the spectrum of possibilities
from what you appear to have in mind at the moment is an approach based on
encoding the recensions as a "repository" which might have three divisions
(encoded as TEI <divs>) where one contained the stanzas unique to witness A,
another contained those unique to witness B and a third contained those
common to both witnesses. (If, as seems likely, there were detailed textual
divergencies between the two witnesses in the stanzas in common, then these
would be encoded as <app>/<rdg> structures associated with the stanzas in
that division.) The electronic equivalent of the print body text would then
consist simply of a set of pointers (in a division or divisions of their
own) from which the processor could build an editorial text on the fly from
whatever components, and with whatever visual presentation, the user
requested. Clearly, under that approach you would not have an <app> where
the editor said in effect "the stanza I have printed in the body text above
is not present in witness B" or "the stanza above is placed between stanzas
N1 and N2 in witness B", because the essence of that information would be
encoded in the sequencing of the pointers (on which basis it could be
dynamically formulated in whatever discursive form was appropriate for the
view the user had requested from the processor, with that formulation
necessarily differing according to the current view).

Incidentally, the approach I've just outlined has the considerable advantage
(though I appreciate it is probably not relevant to your particular text)
that if a new witness or recension comes to light, it can be incorporated
into the existing edition by adding a new division and revising the
pointers, something that is next to impossible with a print-modelled
encoding.

Michael Beddow