[tei-council] Conformance inconsistency

[Christian Wittern]

Syd Bauman wrote:
>
> 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.
>
>
>   
I fear we can make no amendment for P5 1.0 now.   The whole conformance 
issue is something we have to observe closely after its released to the 
wild and make amendments where necessary in future releases.  It is not, 
strictly speaking, just a technical issue and should not impact 
backwards compatibility if we make the set of conforming documents larger.

>> 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.
>
>   
You are right, this is the case where you send me a document before 
transforming it yourself.  In that case, I have to be able to use a 
generic transform to arrive at a conforming document.


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

Well, but in this case, the burden is on you to provide a set of 
transformation rules and either apply them before giving your document 
to me or telling me what do to with it.  Since we currently have no way 
to formalize the latter (except maybe a stylesheet PI), I think it has 
to be the former.

>
> 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.
>
>   
This applies of course only when you strive for conformance.


> 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.
>
>   
I agree that here is some work to be done in the future:  What do we do 
about adding TEI defined attributes to TEI elements?  This should 
probably be a special case, but how exactly deal with it is not 
something I can consider at this time.


Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN