> I guess we're arguing about terminology, then.
> Not if tei_all were to explicitly import the <svg:svg> as a child
> of <figure>, surely?
But Council decided last fall that <svg:svg> would not be a part of
the TEI schema -- a customization will be required to put SVG
elements in your TEI document. (At least, that's what I thought the
> I certainly don't want to disallow customization. In fact, I think
> it's an essential part of helping TEI evolve; expressing proposed
> new elements or attributes as an ODD customization ... is a great
> way of explaining and testing modifications, ...
Absolutely. (I repeated the above in part just because it's such an
important reason to be pleased with how much better than the P4 DTD
extension mechanism is.) And as I have said it is vital, I think, that
proper customizations, including those that permit documents that are
not valid against 'tei_all', be considered conformant TEI documents.
This process is also very useful for "patches" that correct errors in
TEI before the TEI gets around to it.
> But this is futurology, based on the assumption that 640K of RAM is
> enough for anyone...
Right; I'll point out only one more issue before putting down the
crystal ball for now.
> Anyone writing an automatic harvesting system to do a particular
> piece of research, build a metadata database or something similar
... has (for the purposes of this discussion) the same problem today
as he or she will have in 20 years. I do not feel that interchange is
about forcing my data to be accessible by your data harvester.
Interchange is about getting my data to be useful a resource to other
researchers *in my field*. In other words it is more important for
those who study Canadian political journals of the mid 20th century
to be able to share data with those who study American political
journals of the mid 20th century than with those who study Chinese
poetry of the 3rd century.