[tei-council] conformance draft

[James Cummings]

Syd Bauman wrote:

> jc:I'm jc:not jc:entirely jc:convinced jc:that jc:it jc:truly
> jc:impairs jc:human jc:readability. jc:Having jc:a jc:few
> jc:namespace jc:prefixes jc:might jc:actually jc:clarify jc:things
> jc:more.

Surely that would be more accurate as:

<jc:p> I'm not entirely convinced that it truly impairs human <sb:seg>TEI
beginners</sb:seg> readability .</jc:p>  :-)

I actually found the example quite readable, maybe I'm weird.

> Yes, of course, name collision is annoying, and we'd prefer to avoid
> it. But on the scale of problems someone has merging TEI vocabularies
> or getting one project's files to be interoperable with another
> project's software, name collision is extremely low on the list of
> difficulties. (And it's quite rare, to boot.)

I agree. Worries over namespace collisions isn't the only reason to be doing
this.  Yes, they might be a problem, but I'm more convinced of the fact that we
are choosing to put TEI in a namespace.  If we are choosing to do that, then we
should use them properly, and I don't think allowing anyone to add new elements
to that namespace is really using them properly.

> So I see these as reasons to permit a user to separate her additions
> via namespace, perhaps even to encourage her to do so. But to insist
> that the lone scholar studying Hispanic rhyming patterns in
> 17th-century manuscripts create his own namespace and deal with
> multiple namespace issues for the one element he wants to add to
> enhance his research (or lose the funding-helpful claim to "TEI
> Conformance"); or worse yet, to risk having an administrator worry
> that, like copyright infringement, it's illegal to add elements in
> the TEI namespace ... all for a limited technical gain that may never
> occur, seems like a bad idea.

Firstly, let's not make 'create his own namespace' into more than it is... if
Roma were edited as Sebastian suggests to provide a namespace, etc., then the
barrier isn't that high.  Ok, there is still a barrier on 'deal with multiple
namespace issues' for his one element.

On the phone it has been suggested to me that a compromise might be something
like this:

a) Remove mentions of namespaces from the definition of TEI Conformance.
b) Include that the document must validate against one of the schema categories
listed in order to be conformant.
c) Add a new category which is
'extension-but-doesn't-use-TEI-namespace-for-new-elements'.
d) Add new-elements-in-new-namespace-requirement to a definition of 'TEI
Interchange Format'

An alternative possibility is to leave namespace-for-new-elements as a concept,
but not a requirement for conformance, and instead make it a requirement for
'TEI Interchange Format', but provide users an easy route to gain this to show
their funding bodies.  I.e. Roma or a Roma-like tool reads an ODD and will
generate non-colliding schemas that use no-namespace for local processing, and
one which uses namespaces and an XSLT which will transform document instances
that validate against the no-namespace version into documents with namespaces.
While I think we should be providing as much help in this area as possible, I am
not sure this promotes best practice.

Part of the problem is that funding bodies want to see funded projects using
'the best' method possible.  While often this sense of 'best' is based entirely
on misunderstandings, if we have TEI Conformance, and then TEI Conformance+TEI
Interchange Format, they'll probably just view that as better and require it.

-James

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