> I have been advised to specify which elements I was intending to
> move into a different class, because doing so might have some
> terrible effects.
Well, yes, but you'd find out soon enough :-)
> I was mostly thinking of moving FW to Incl. (A habitat of empty
> elements, I know.)
As you mention later, I approve; in fact, it's the example I pointed
to in my previous response.
> But then, all the discussions seem to have petered out before some
> final judgement was passed on the idea.
Unless a problem is deemed a corrigible error, you will probably
never see "final judgement" passed here on the list. For better or
for worse the TEI functions by having work groups examine an issue
and make recommendations. I think this system is generally for the
better, although it is a bit cumbersome and somewhat expensive, which
means that we currently do not have a workgroup addressing this
issue. (One of the main advantages of consortium membership, as I see
it, is to influence which workgroups get created to solve what
> Two other elements I had thought to add to Incl: DEL and ADD.
I agree that <add> (like <note> and <anchor>) should be allowed most
anywhere. It's hard to imagine where in a document an author couldn't
scribble in an addition.
> As other people who've posted to this list, I'm unhappy with
> addSpan and delSpan and all that business with anchors and XSL
I may have missed something, but I don't recall any mention of this.
> If anyone could tell me how to EFFICIENTLY process <delSpan>
> together with <del> XSLT-wise, could you please contact me
Actually, I, for one, would prefer the answer be posted here. I think
this *is* TEI related (although a little less directly so), and it's
quite likely that I'll want to know someday, too.
> Since I abhor <delSpan> and <addSpan>, I've worked around these
> by using <del> and <add> on single lines, ie:
> <!-- ... -->
Since I do not share your abhorance of <addSpan> and <delSpan>, it's
hard for me to see why you'd do this. It seems it will certainly
confuse any processor that, e.g., wants to count the number of <l>s
(I'm presuming, of course, that you have a processor that is smart
enough not to count an <l> that is within <del> or a section marked
as deleted by <delSpan> -- if you have such a processor (that is not
PC-specific), could you send me a copy? :-)
> ... possible <lg rend="deleted">
I don't think I like overloading rend= like that. But it might make
perfect sense to add a new global attribute, present= with only two
possible values "stet" (the default) and "nuked". (I did not use
deleted=, "yes", and "no", because there are other attributes that
have values "yes" and "no", and SGML won't allow them both on the
same element.) With some foreshadowing to your next post, could also
make it deleted= with "stet", "scribal", and "editorial".
I realize I haven't addressed everything you posted yet, but I've got
to go cook dinner. Hope this is at least interesting if not helpful.
 Errors are corrigible if and only if:
* the text is obviously wrong as published, and no reasonable
case can be made for the TEI scheme to work that way;
* there is an obvious fix;
* the fix is backward compatible: fixing the error will not make
any legal documents suddenly illegal.
(ED W 57)