[tei-council] conformance draft

Lou Burnard lou.burnard at computing-services.oxford.ac.uk
Mon Apr 2 16:43:08 EDT 2007


Sebastian said
> 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 1.3.3.2.  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 
conformant schemas.

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 
1 above)

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 mailing list