Thanks all for this provocative discussion. 

On the question of <lem>/<rdg> (and implications for one's relationship vis-a-vis the "New Philology"), I will largely dodge the question. Marjorie, responding to Peter, writes:

> Of course. In this case, you will certainly agree that if someone (Chris Forster namely) encodes a textual phenomenon like this:
> <l>I will arise and go now<app><lem wit="#A">,</lem><rdg wit="#B" /></app> and go to Innisfree</l>
> he means that he has made a decision, for whatever reason, that witness A has the right reading, and witness B is *omitting* the comma? > Otherwise, he would have encoded this phenomenon like that:
> <l>I will arise and go now<app><rdg wit="#A">,</rdg><rdg wit="#B" /></app> and go to Innisfree</l>
> So when Chris wants to transform his encoding into a print version, categorising the absence of comma in source B as an "omission" is *not a problem, but a feature*.

Indeed. I have chosen to encode <lem>s within the apparatus rather than just <rdg>s not because of preference or belief their better reflect authorial intention, but because a fidelity to a particular state of the relevant document. The edition is really an edition of the 1922 *Harlem Shadows* which then encodes variation relative to it. So, Hugh's point that " If you were picking one as your base text or establishing a base text and favoring one reading over the other, then it would be obvious how to treat A and B," seems right to me, and indeed, in my case, is how I understand it. Peter's points about the complexities of what selecting what a "lem" might mean, and the differences between copy text/base text/master text, all seem apposite. I am not a textual critic by training; I am invested in putting together a usable edition that captures the range of textual variation as completely and transparently as possible. The choice to use the 1922 text, in my particular case, as a base text against which to mark variations seems in some ways arbitrary (I have no interest in making any arguments about that text with regard to McKay's intentions, or inherent quality), but also defensible since it is a key text for historical reasons (often cited as helping to inaugurate the Harlem Renaissance).

And because this (quasi-arbitrary decision) provides a still point against which differences can be easily described (this is omitted, this added), it seems to have a number of benefits from the perspective of both encoding and output transformations. I have tried to encode it such that one can easily reconstruct any existing state of the poem--see, for instance, in addition to the "Highlight Variants" checkbox, click the title of other versions to see how the text appeared in that state (e.g. clicked the link on *Pearson's Magazine* on this page,, to see how the text of the poem as it appeared in *Pearson's*).

I appreciate Franz's suggestions for alternative nomenclature to om. and add., though as Franz suggests, I think intended audience might make Latin a... surprising choice. ;)

Regarding Elisa's point about the practical matter of XSLT transformation; I can add om. and add. quite easily I think; the more attractive solution, proposed by Bertrand, which would involve more context, that sounds more complicated. I can sort of imagine how to do it, but I think it would get ugly, b/c one would need to move up the xpath tree from the <app>, without knowing whether they would move one out of the current block-level element, and so on. So, while I think the print solution proposed by Bertrand is the easiest to understand, I think the more simple "om." and "add" are likely a better choice. (And fortunately, I am dealing with a text that is short enough, and invariant enough, that I'm not sure the problem of ambiguous reference ever comes up!)