[tei-council] conformance draft

[Syd Bauman]

I have finally gotten to reading James' draft
(http://www.tei-c.org/Council/conformance-draft.pdf). Thanks to James
for doing this work. Overall I think it looks quite good. However, I
have lots of nit-picks (some of which others may have noted already),
two procedural issues, and a few major points to raise. I am going to
skip the nit-picks for now, mostly because all of Council need not be
bothered.

I will post the procedural issues separately, as they are less
important, and may be uninteresting to many Council members.


So, on with my main issues with the draft conformance chapter.


One: ODD validate against which schema?
---- --- -------- ------- ----- -------
At several points the chapter refers to the need for a "valid TEI
ODD" file. This is well and good, but valid against what? I don't
think it will be particularly difficult to come up with a statement
against which schema such an ODD should be valid, but such a
statement is, I think, necessary. And it isn't trivial. E.g.,
Roma-the-web-app often produces ODD files that are invalid with
respect to the schema that I would expect them to be valid against.
(Currently the 0.6 version of P5/p5odds.rnc, available at
http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/p5odds.rnc.)


Two: Exemplars
---- ---------
I feel that too much weight is placed on the TEI Customization
Exemplars, although I don't have specific suggestions for improvement
at the moment. These exemplars are primarily intended to be examples
of how to perform specific kinds of customizations (e.g., including
SVG) or to be good starting points for customization, but are not
intended to generate schemas that are useful for encoding, and
indeed, they don't. Most obviously, they do not provide controlled
vocabularies for data.enumerated attributes.


Three: Schemas
------ -------
I think it is important to make it clearer that validation against a
schema is a necessary, but insufficient, condition of conformance --
that there are constraints required by the Guidelines that are not
schema-enforced. (E.g., that a hand= attribute point to a <hand>
element, not an <emph> inside a <salute>.)

Furthermore, I think it is important to explain that DTD validation
will not inform a user about as many constraints as will Relax NG
validation. (E.g., many attribute values have datatypes that provide
useful constraints in RelaxNG-land, but are just CDATA in DTD-land.)


Four: namespace of new elements
----- --------- -- --- --------
I am not at all sure it is a good idea that TEI require that new
elements be in a separate namespace. I think that doing so
* creates a higher barrier to actual use of the customization
  mechanism
* makes instances harder to read by humans
* sends the wrong message politically -- that if you create a new
  element, somehow you're not a member of the same TEI club
for an extremely limited technical gain. Rather than make this a
condition of conformance, I would like to see the definitions of the
various categories of TEI-Conformant schemas (& documents)
differentiate based on use of namespaces.

So, e.g., rename "Extension Schema" to "Pure Extension Schema", and
create a new category "Extension Schema", which permits the addition
of new elements in the TEI namespace.


Again, thanks to James for doing the footwork, here.