[tei-council] conformance chapter

[Lou Burnard]

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 
between classes?