[tei-council] conformance chapter

James Cummings James.Cummings at computing-services.oxford.ac.uk
Fri Jul 21 07:27:32 EDT 2006


Lou Burnard wrote:
> 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?

I vote to get rid of all mention of it in general (except in the Gentle
Introduction or anywhere we want to indicate the history of XML and the TEI.)
Theoretically, the TEI Guidelines are the important thing, that they happen to
express the markup currently in XML is a (possibly transient) choice because of
its popularity and applicability at the moment.  If something better comes
along, I don't think the TEI has a commitment to not choose to move to that (in
the far future).  Does it?

> 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.

What is ESIS again?

> 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.

I think we should say that TEI conformance should be XML based.  However, I
think we can say that people can use local encoding formats where they have used
ODD to define new elements, <equiv> to document renamings, etc. and that they
can also move up (erm down?) sebatian's levels to be more conformant by
resolving these for their 'interchange'  (or perhaps 'archival' ?) version.


> 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.

Transmission is much less of an issue these days, no?

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

Not under Sebastian's levels.  Are fragments of a TEI document which also
validate against a separate TEI schema TEI conformant documents?  I have an ODD
that allows me to have <div> as my start element.  Which means that I can have
lots of separate files which are then imported into a larger master file which
has a TEI header, etc.  Since this ODD makes no other changes to the TEI, and
the <div>s are in the TEI namespace, and use only TEI elements, are they
TEI-conformant documents?  Or are they only so when combined all together with
the header?  Under Sebastian's levels (if I'm not mistaken) these would be TEI
conformant, under the above, they would not.

> d. 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?

Hrmmm. I think I'd need to have the consequences of this explained to me several
times. :-)

-James
-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk




More information about the tei-council mailing list