[tei-council] conformance draft

[James Cummings]

Syd Bauman wrote:
> I am going to
> skip the nit-picks for now, mostly because all of Council need not be
> bothered.

Do feel free to pass on the nit-picks privately.  That which doesn't kill us...

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

Make sense, agreed that this should be more specific.

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

My suggestion is that the discussion here should lessened, but that they be 
discussed in more depth in the chapter on customisation/modification.

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

Yes, that should be stated more clearly.


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

While DTD validation may not provide as many constraints, if the document 
instance validates against a DTD generated from a TEI ODD is the document 
instance somehow less conformant than if it is validated against a Relax NG 
schema generated from the same ODD?  Either DTDs are acceptable to validate TEI 
Conformant documents against or they are not.  I admit that I have a little 
niggle worrying in the back of my head about someone creating an ODD for a 
schema which would be considered in one of those categories of TEI Conformance, 
but that the lack of constraints in DTD means that document instances which 
validate against the DTD are non-conformant because they don't include certain 
constraints in the Relax NG version generated from the same ODD.  (Can someone 
invent an occasion where this might happen that simultaneously breaks 
conformance?) Maybe we should think about that more.

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

I think I'm still going to try and take the moral high ground...I recognise that 
it creates a barrier to use of the customisation mechanism.  I'm not entirely 
convinced that it truly impairs human readability.  Having a few namespace 
prefixes might actually clarify things more.  I'm entirely used to xml:id now as 
an attribute.  I don't think it sends the wrong message politically either...or 
at least you can view that in two ways.  When you create a new element you get 
the privilege of putting it in your own project's namespace, and the comforting 
knowledge that the TEI namespace is kept pure.  When you use other TEI documents 
you know the elements and their semantics because they are in the TEI namespace. 
    I will admit that I am torn...I understand how much of a pain it is to do 
things in multiple namespaces even just in writing XSLT stylesheets, never mind 
full-blown applications.  As an elected member of the council I feel I'm here to 
support the interests of the members.  However, I'm torn between doing what I 
feel is right and doing what is easier.  Would the membership want me to make 
life easy on them, or really make use of namespaces in the way I feel we should?

The only real objection anyone has made so far concerning the 
use-your-own-namespace-for-new-elements idea is that it is difficult.  Does 
anyone have any other arguments against this idea?

While I unquestioningly accept that the use of namespaces in this way means that 
it will be more difficult to use the customisation mechanism, it might not pose 
an insurmountable difficulty or dissuade people from customisation as much as we 
might expect.  Partly that depends on front-end applications like webRoma.  If 
when I add a new element it is also prompting me for the namespace (perhaps with 
a previously-used suggestion) or something, then the barrier to use is lessened. 
  Couple that with some XSLT examples handling multiple namespaces and a lot of 
the fear is reduced.

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

This is certainly a possibility. Would the lack of namespace only occur in this 
category of schema?  And even if the current conformance draft was the final 
chapter, this is something I think many people would probably do.  If we persist 
with this use of namespaces I think there will be an increase in local encoding 
formats with transformations to multi-namespaced TEI Conformant documents only 
for interchange/deposit-with-archives/pleasing-the-funders, and such.  But if 
using multiple namespaces is still the 'right' thing to do...then should this 
dissuade us?

No one has said anything about the section 1.7 'TEI Conformance and Funding 
Bodies', since the claim of TEI Conformance is something that is often added to 
funding applications (since I read scores of them for the AHRC) in hopes of 
people saying "look how good we are, please, please fund us", I thought that we 
should say something about Conformance in no way indicating quality.  However, I 
wasn't quite sure how far we should go along that road or other appropriate 
messages, etc.

-James

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