[tei-council] conformance draft
lou.burnard at computing-services.oxford.ac.uk
Mon Apr 2 16:43:08 EDT 2007
> er, um. yes. I meant to say I am relieved we are
> discussing just this in some detail, as it implies
> the rest is generally accepted.
Not so fast Red Baron...
1. The definition of "recommended practice" used to have a third point:
"all textual features which the guidelines recommend be captured are in
fact encoded. "
which James removed presumably because he could think of no case where
the Guidelines actually makes recommendations about the level of
encoding to be applied (i.e. where it suggests that you really ought to
mark up paragraphs, say, or lines in verse)
2. The original draft distinguishes two formats for a conformant document:
"A document is /TEI-conformant/ if it is either in /TEI local processing
format/ or in /TEI interchange format/. A full description of the
document should specify which format it is in."
The new draft does not make this distinction up front, although it is
discussed later on at 22.214.171.124. Was this a deliberate decision or an
oversight? Should we not make the distinction earlier? I can see that
the case for a third possible format originally discussed ("TEI packed
interchange format") is hard to maintain with the availability of XML,
but maybe we ought to preserve the other two?
3. The discussion of a "TEI derived schema" (1.2.2 in the current draft)
talks about ODD-derived schemas and about exemplars, but does not
mention the feasibility of constructing a TEI schema by combining either
DTD fragments or RelaxNG fragments. Are we specifically outlawing that
approach, or are we just passing over it in silence? I don't think
either approach will win us any friends.
4. The suggestion that a sourceDesc element is no longer required seems
unwise to me. If a document is "born digital" the fact should be
stated, and the sourceDesc is the place to do it.
5. 1.2.5 introduces a new term "TEI compliant" but does not seem to
define it anywhere: is it meant to be synonymous with "TEI conformant"?
6. As others have suggested, the list of exemplars should probably move
somewhere else. Except that the definition of tei_all is important,
since it's used in the following section to define varieties of
7. I am a bit unclear about the purpose of a "TEI Supported Extension
Schema". Can anyone suggest one? what does "is supported (to some
degree) by the TEI" mean?
8. The last bullet point in the list at the start of 1.3.3 (requiring
the existence of an ODD to document the schema used by a non conformant
customization) while I agree with it in principle is (a) not a property
of a document (b) somewhat at variance with my point 3 above.
9. I don't like section 1.7 much: it makes me feel uneasy. We are not in
a position to tell funding bodies what they should or shouldn't think,
and even if we were it shouldn't be a topic for this chapter. We ought
to be clear first about what *we* mean by TEI conformance, and although
I think this discussion is clarifying that quite a lot, we ain't there
yet. Issues of "superior quality" and "greater academic scrutiny" surely
relate to matters which are out of scope here (see for example my point
Let me repeat that I think this draft is definitely going in the right
direction, despite these somewhat picky comments! I think it's really
important to get a good version of this chapter into draft 1.0 so I hope
we can focus on that for a while..
More information about the tei-council