Each of the blobs here represents three subtly different things:
- an ODD : that is, a collection of TEI specifications
- a formal schema generated from that ODD, and its natural language documentation
- the set of documents considered valid by that schema.
The TEI provides TEI All : a set of over 500 uniquely identifiable elements, classes, attributes, etc. and a schema in which they are all permitted. For all practical purposes a user of the TEI must make a selection from this cornucopia, and we call that selection a TEI subset. Of course there are many many possible TEI subsets, each making different choices of elements or attributes or classes, but the sets of documents which each consequent schema will validate all have in common that they will also be considered valid by the schema TEI All.
A user of the TEI may however do more than simply choose a subset of the provided specifications. They may also provide additional constraints for aspects of an encoding left underspecified by the TEI, for example by requiring that attribute values be taken from a closed list of possible values rather than being any syntactically valid token. They may simply change the datatype of an attribute, for example from a string to an integer or a date. They may also provide an alternative identifier for an element or an attribute, for example to change its canonical English name for one from another language. In some cases, attribute value changes are equivalent to a subsetting operation; in others not. Renaming operations never result in a subset: a document in which the element names have all been changed to their French equivalents cannot be validated by an English language version of TEI All. A user of the TEI can also change the content model or the class membership of existing TEI elements, in ways which may or may not be equivalent to a subsetting operation.
We use the term customised subset for all these kinds of personalisation because they result in something which is not necessarily a further subset of the TEI subset concerned, but a further modification of it. In the general case, their conformance with TEI All can be determined only by inspection, and their validation may require some additional processing.
Finally, a user of the TEI is at liberty to define entirely new elements and attributes, and to make such components members of existing TEI classes so that existing TEI elements may refer to them. They may also modify the content models of existing TEI elements to refer explicitly to such new elements. This results in an extended subset, since it contains elements or attributes additional to those provided by the TEI All schema. Such additional components should always be labelled as belonging to a non-TEI namespace. A processor can then determine that these components may be left out of consideration when determining the validity of a document with respect to TEI All.
In additional to these formal considerations, TEI conformance involves attention to some less easily verifiable constraints, specifically the twin requirements of honesty and explicitness. By honesty we mean that elements in the TEI namespace must respect the semantics which the TEI Guidelines supply as a part of their definition. By explicitness we mean that all modifications (i.e. both customized and extended subsets) should be expressed using an ODD to document exactly how the TEI declarations on which they are based have been derived. (An ODD need not of course be based on the TEI at all, but in that case the question of TEI conformance does not arise)
Formally speaking, we can say of a conformant TEI document :
- it must be a well formed XML document and
- it is valid against the TEI All schema :
- without modification (it is a TEI subset), or
- after deletion of any elements it contains which are not in the TEI namespace including their children, irrespective of namespace (it is a TEI extension), or
- after application of any canonicalization algorithm specified by its associated ODD (it is a TEI customized subset)
The purpose of these and similar rules is to make interchange of documents easier. They do not however guarantee it, and they certainly do not provide any guarantee of interoperability. Unlike many other standards, the goal of the TEI is not to enforce or impose consistency of encoding, but to provide a means by which encoding choices and policies may be more readily understood, and hence (to some extent) algorithmically comparable.
OpenEdition vous propose de citer ce billet de la manière suivante :
foxglove (14 mars 2017). Notes towards a definition of TEI Conformance. Foxglove. Consulté le 6 décembre 2024 à l’adresse https://doi.org/10.58079/otm8
[If you’re wondering, this became a talk I gave in Heidelberg, and then again virtually in Victoria: see https://www.youtube.com/watch?v=VZHrgzQOSWE … or read the text here http://bit.do/tei-conformance ]
I like the concepts of honesty and explicitness, at least within limits.
The main problem with honesty is that while it provides simple and useful guidance to users of TEI and constructors of TEI modifications, it may be very hard to reach agreement on whether a specific use of TEI is honest or not, and even harder to check mechanically.
Explicitness is good, though some eyebrows might be raised at the implicit suggestion that TEI ODDs provide the only relevant standard of comparison for explicitness in vocabulary definition. Given that the purpose of an ODD is to customize the document grammar specified in the TEI Guidelines, it does seem a bit odd that it provides so few mechanisms for relating one element or content model to another: no way to say whether a revised content model is intended to be a restriction, an extension, or an equivalent restatement of the original; no way to say “this element in my namespace is exactly like that element in the TEI namespace, except for …”; no way to say “this element can appear in exactly the same places as / as an alternative to that TEI element” (as the XSD substitution-group mechanism allows), etc., etc. I’m not suggesting that ODDs need to be revised or redefined, only that some formulaic expressions of humility will make the prescription of ODD as *the* mechanism for achieving explicitness less likely to elicit rude laughter from observers familiar with other mechanisms.
I’m a little less enthusiastic about the mechanism described in the final bulleted list (which I take to be a gesture in the direction of formalizing honesty). You say that conformance testing involves construction of “a schema … to validate those elements [the document] contains from the TEI namespace”, and then checking to see whether the language accepted by that schema is a subset of the language accepted by TEI All. (Well, strictly speaking, that’s not true. You don’t say this is how to check for conformance. You only say that in a conformant document, the properties described will hold. I’m assuming a direct attempt to check the property, because you don’t describe any other mechanism.)
Before one can consider whether this is a good idea or not (looks like a bad idea to me, at first glance, or at best an unmotivated one), the idea needs to be made more precise. Several questions arise:
How does one define the schema of which you speak?
Given that the document we are starting from may contain some elements in other namespaces, what does the schema we are constructing say about those elements?
What is the relation of the schema to the document whose conformance we are testing?
Most documents for which the question of TEI conformance is of interest are constructed to conform (if I may use that word) to a particular profile or modification of TEI specified in an ODD document. What is the relationship of the language accepted by this constructed schema to the language defined by the schema generated from that ODD document?
Is it necessary to construct a separate schema for each TEI document whose conformance is to be tested? Would it be possible to construct the schema by modifying the schema defined by the relevant ODD document?
Is it necessary to construct a special TEI-only schema in the first place? Is it not possible to define an appropriate relation between the ODD-specified schema and TEI All, or between the languages defined by them? Or to impose an appropriate constraint on the elements of the TEI namespace within documents valid against the ODD-defined schema? What is the motivation for defining an ODD document, generating a schema from it, constructing a document to be valid against that schema, and then ignoring that schema for purposes of conformance testing and constructing instead a different schema?
Thanks for your comments.
I agree that defining honesty (or identifying dishonesty) is hard and for some edge cases may be impossible, but its appeal to common sense knowledge makes it more attractive to me than any amount of theoretical modelling.
I suggest that the model class is the mechanism used by ODD at least partly to address the needs you enumerate for a way of expressing relationships amongst element. There is also the equiv element.
I’m persuaded by your argument about the “other” schema however. It’s unnecessary. We define a validation procedure that suppresses non-TEI elements in our documents and we’re done.