I've begun work on the critical apparatus issue, building on what Cara has already done, reading through all the relevant P5 Guidelines sections and playing around with JUXTA. There are a number of questions we need to answer before we can move forward with this, and I think they'll need some thought and discussion:

1. I'm starting from the assumption that we want our witness and collation data to be encoded in P5, but we still need to decide exactly how that should be done. Specifically:
   • Should witness and collation information be kept separate from the main transcription document? (I think this is advisable, because it will bloat the document and make it hard to edit otherwise.)
   • If so, should witness and collation information for each poem be kept in a separate file, or should they all be encoded in one large document? This rather depends on the number of witnesses each poem has in common. If many poems in the base text have witnesses that appear in the same external source, then it would make sense to centralize the witness and collation information into a single file. If, on the other hand, there are few instances of this, then we could create a separate witness/collation file for each poem. The latter will obviously result in smaller files which are easier to edit and manage.
   • If the apparatus is external, how should it be linked into the locations in the base text? The most appropriate method recommended in the Guidelines would seem to be location-referenced, with a loc attribute on the <app> tag, its value consisting of the xml:id attribute of the target poem div, followed by a space, followed by the line number in the target poem. Will this work reliably? Are there circumstances in which variants will need to be encoded which refer to a location in the base text which is not identifiable in this way?
   • Should metadata about the witnesses themselves be kept in the same file as the collation/variant data? All witness metadata could be listed in a separate file, referenced by all the collation files. This would centralize and information and ensure that only one copy of the same information exists (i.e. there's only one description of any particular witness). On the other hand, if there are no witnesses in common between different poems, then there's no point in this; we can keep witness metadata in the same file as the apparatus itself.
2. How are we going to generate the P5 collation information? There seem to be two approaches to this: one is to use Collate, as Cara has done, and then write a little application to process its data into a P5 file. I'm going to write a little Java thing to do that. The other is to use Juxta, which I'm investigating at the moment. Juxta can produce an XHTML apparatus, which I think could be fairly easily processed into P5 using XSLT. Cara has reported that she got unreliable results with Juxta, so we'll have to test it carefully to see if we can rely on it.
3. We need a set of sigla (taking a form which is usable as an xml:id attribute) for the witnesses. The collations Cara's created with Collate use the file name of the text file containing the variant. This would do perfectly well, but we need to list and document all the sigla in a <witList>.
4. How are we going to output the information? Ray wants to see something that looks like a traditional critical apparatus, which should be easy to reproduce, but where should that appear -- at the bottom of the poem page, or alongside it? If alongside it, how do we tackle the problem of the apparatus having more text than can be accommodated while keeping it synchronized on the page with the base text? Should lines for which there are variants have a little clickable symbol next to them, which will pop up the apparatus for that line?
5. Do we intend to make the apparatus so precise as to enable the complete reconstruction of all witnesses from it? If so, we'll need to be much more precise in encoding the start and end points of each apparatus entry. Personally, I'm not sure that this is worth the trouble, because in any case we'll have to generate either text files (if we choose to continue using Collate) or special markup files (if we use Juxta) for each witness anyway; it would make more sense to read and output those if necessary, rather than laboriously reconstruct variants based on our apparatus markup. However, the ability to reliably reconstruct texts would give us more flexibility in terms of creating interesting and innovative display formats in the future.

I'd like to get some feedback on these questions before I carry on.