WP> Maybe a parameter entity with a switch,
RL> That approach would get my vote.
I'll take Richard's comment as a write-in for my #4; can
Wendell switch his vote for #3 to a write-in for my #4?
> [F. Lachance and P. Durusau ask about backwards compatability.]
SR> Make them all CDATA. Otherwise old documents may break.
Although it is true that existing documents that are valid against
"-//TEI P3//DTD Main DTD Driver File 1994-05//EN" may not be valid
against "-//TEI P3//DTD Main DTD Driver File 2001-10//EN" (or what-
ever), I'm not sure that this should stop us from making improvements
to the TEI. We don't plan to force people to purge older versions
from their systems, do we? (I hope not -- I havent' even upgraded
the WWP from the original P3 DTDs to the improved 1999-05 version.
BTW, I was unable to find an FPI for that version; I presume it
would be "-//TEI P3//DTD Main DTD Driver File 1999-05//EN".)
SR> The philosophy of the P4 TEI is to keep old documents working,
SR> even if some constraints are loosened.
This is a philosophy I was not aware of; nor do I think I approve
of it, although I haven't put much thought into it yet. Is it
promulgated anywhere? The TEI is, at least in part, a research
project (remember, the "P" stands for "proposal"), not a commercial
product. If making it better includes making it more restrictive,
then so be it, IMHO.
I also think M. Beddow's point that changing from CDATA to IDREF is
also "breaking" things is very true, and quite important. (The crazy
analysis of SIC w/CDATA, CORR w/IDREF I don't buy; note that both
ABBR and EXPAN use IDREF, but both ORIG and REG use CDATA.)
SR> But think of the precedent it [option #4, parameter entities]
SR> sets. If you permit this, there are a thousand other places where
SR> a similar request might be made.
Yes, and thinking about those requests and acting on a good number of
them would be an excellent thing for the TEI to do. (Although it
might well be argued that putting the same time into schema would be
Please don't mistake me -- I am all in favor of using post-DTD
validation processes (ours here, called "supra-validatoin" is written
in Perl, not XSLT, but that's not the point; if I had my druthers I'd
rewrite it from scratch, quite possibly in Python or XSLT); I am also
in favor of serious consideration of shifting to XML schema (likely
XML Schema) validation instead of DTD validation. But neither one
means that work on the current DTD should therefore be limited to
avoid any "restrictive" changes (those for which some theorhetical
document instances that are valid against the current vanilla TEI DTD
will not be valid against a TEI DTD with the given alteration as the
On the other hand, I wish it were a lot clearer in the Guidelines to
what element the IDREF resp= should point.
Lastly I will point out that using IDREF for resp= of NOTE is a bit
of a problem: perhaps the "Sample values include" section should be