[tei-council] conformance chapter
lou.burnard at computing-services.oxford.ac.uk
Fri Jul 21 06:45:05 EDT 2006
Thanks to Sebastian and James for providing some thoughts about how to
start revision of this chapter. It would be useful to hear from other
members of the council too, of course!
To get your juices flowing, I have the following immediate thoughts:
a. Let's get rid of SGML
Much of the current chapter is concerned with the complications inherent
is saying that a TEI document must conform to an SGML DTD. Do we want to
retain all that baggage for P5?
How do people like the following propositions:
1. A *TEI-conformant* document must be a valid XML document.
2. An SGML document whose ESIS is the same as that of a given
TEI-conformant document is *TEI-compliant*
3. A TEI-compliant document must be converted to an XML representation
before it can be validated for TEI conformance.
The current chapter distinguishes "TEI local processing format" from TEI
interchange format". This distinction is that the latter may not use
SGML minimization features. If we say that TEI conformance is only true
of XML documents, then such features are not allowed anyway, so the
distinction is not needed.
b. Transmission and packing
The current chapter also talks about transmission formats, and in
particular ways of packing TEI document components together. I am not
sure that we want to keep that either, since whatever we say will
rapidly be as outmoded as the current vague reference to SDIF is.
But if we do want to say something, then it would presumably be here
that we should discuss that old chestnut about how a document instance
identifies the schema used to validate it.
c. Sanctity of the header
The current chapter (in 28.3) makes two (2) requirements of a TEI
conformant document "after modification" -- both relating to the header
and mandatory parts of it. Do we still believe these? To put the
question more acutely, if an ODD defines the TEI Header out of existence
is a document conforming to it ipso facto no longer TEI-conformant?
d. abstract model
The chapter introduces (28.1.5) some other terminology: "TEI recommended
practice" and "TEI abstract model". I have no trouble with the former,
but the latter is a little tricky. It says "A document follows the TEI
abstract model if it tags the features specified in the TEI
documentation and their structural interrelations agree with those
specified in the TEI DTDs". Leaving aside the question of whether "tags
the features" should be read as "tags *all* the features" or "tags some
of the features" or "tags only features", I wonder whether we have a
problem with the "structural interrelations". Changing the membership of
a class probably doesn't affect the abstract model (in this sense), but
changing the class hierarchy itself certainly does. So if I make an ODD
in which class foo, formerly a subclass of bar, becomes a subclass of
baz -- I may well put several holes in the "abstract model"
Would be on comparatively safer ground if we said that the abstract
model is defined in terms of the existing classes. So you can change
elements' membership in a class, but you can't change the relationship
More information about the tei-council