[tei-council] Conformance inconsistency

[Syd Bauman]

Thank you, Christian, for your thoughtful analysis. This reply is in
true haste, as I am really just taking a break from proofreading IM.

> As you will see, one is talking about a schema, the other about a
> document instance. Conformance is only relevant to document
> instances, (see the beginning of 23.3, where it says <q>The notion
> of /TEI Conformance/ is intended to assist in the description of
> the format and contents of a particular XML document instance or
> set of documents.</q>)

But, of course, a schema defines a set of documents. :-)


> [quoting 23.3.4:]
> ... cannot be considered TEI Conformant, though it may be TEI
> Conformable.

This is also an inconsistency, because 23.3 makes clear that a "TEI
Conformable" document *is* TEI Conformant.

If I may raise this issue yet again, this kind of descriptive
difficulty will go away if we develop a name for the category of
things that are TEI Conformant but not in the subset called
"algorithmically conformant" aka "TEI Conformable". If no one likes
my suggestion of "Strictly Conformant" then please, let's think of
another name and use it. But this idea of having a superclass ("TEI
Conformant") that divides the world into two sub classes, and only
naming one of them ("TEI Conformable") is going to cause trouble --
no, is already causing trouble.


> Algorithmical transformation of course has to work without looking
> at the specifics of your document, so it can more or less only be a
> transform that simply takes out everything which is not in the TEI
> namespace. 

This is a far stricter definition than that which is in (my reading
of) CF, and one that I have a problem with. My belief is that this is
the definition of "TEI Conformant but not in the subset of TEI
Conformable" (i.e., what I'd like to call 'TEI Strictly Conformant'),
not of algorithmic conformance.

Consider what happens if we do not allow the transform that takes TEI
Conformable documents and makes them into what I would like to call
TEI Strictly Conformant documents to know the specifics of my
document, if the transform is forced to just discard anything in a
non-TEI namespace. The simple stuff which (I believe) we had in mind
in Berlin would not be possible. E.g., syntactic sugar. 

So I claim TEI Conformable *has* to be more than this, else it does
not even serve its most basic purpose.


It makes me quite sad that we've made it so easy to customize TEI,
but so hard to customize it Conformantly. We spent years working on
the class system, including compromising some content models, etc.,
but because of the strict definition of TEI Conformance some of its
advantages are lost for users.

If that isn't obvious, BTW, think of the user who wants to use both
<bibl> (for printed books) and <biblFull> (for TEI-encoded resources)
in her bibliography. Like us, she wants two different kinds of
entries, one that's the citation for a quotation, one that's a
suggested reading. Unlike us, she wants them all in a single <div>,
and plans to differentiate using type=. But lo! Unlike <bibl> and
<biblStruct>, <biblFull> doesn't have a type=. Well, for years we
have been spouting the benefits of the TEI class system. All she
needs to do is go into Roma, go to the Modules tab, click on
"header", then click on "biblFull", then click on "att.typed", then
click on the submit query button and presto! She can generate a
schema which supports her needs.[1]

But not if she wants to be conformant. Since an instance with type=
on <biblFull> is not valid against tei_all, it is not conformant in
its own right. Because there's no equivalent TEI construct, it can't
easily be transformed into something that is valid against tei_all,
so it is not TEI Conformable.

In order to meet her encoding needs conformably, she needs to eschew
the ease of the class system and either:
a) generate a new my:type= attribute for <biblFull>, 
b) generate a new element, <my:biblFull>, which itself can be a member
   of att.typed, or
c) use a different namespace for her entire document.
In case (b), if <biblFull> were required in the content model
of some other TEI element, that element too would need to be
redefined outside the TEI namespace, as its content model would no
longer be satisfied by the <my:biblFull>. And on up the chain.

Notes
-----
[1] She should, of course, go in and create a controlled vocabulary
    for type=, but that's not germane to this discussion.