[tei-council] MD chapter revised: namespace rules

[Lou Burnard]

Syd Bauman wrote:
>
> Your logic completely escapes me. What's wrong with two different
> barriers? After all, we are talking about two completely different
> use cases. The first, well thought out, documented, and dealt with by
> the creators of P3, is the barrier for document creation, processing,
> and to a lesser extent, interchange. This is the barrier called
> "conformance", which I would like to see set reasonably low. The
> other is the barrier for interoperability, a goal that has never
> really been discussed in previous versions of the Guidelines, and
> which requires a much higher barrier.
>   

Where on earth did you get the idea that P3  doesn't talk about 
"interoperability"?
There's a whole chapter on it! The point though is that everything in it 
is  redundant in the world of XML.

I also think that you're unlikely to persuade anyone to agree with you 
until you come up with some definition of what *you* think 
TEI-conformance means.
>
> Remember that with P3/P4 we set the barrier to conformant
> customization too high, and the result was that most projects used
> TEI Lite, and many hacked it directly. 
What barrier did we set? you just said there was nothing about 
conformance in P3, and now you're saying that we made it too difficult? 
make your mind up!

> I disagree. I think there are advantages both for the TEI and for
> users to using the Guidelines for text encoding, not just for
> interchange with the hope of interoperability. For starters, such
> projects will have both less incentive to be TEI-C members, and less
> ammunition when they talk to their deans about becoming TEI-C members. 
> ("OK, so you transform it to TEI to put it in an archive, so what?
> You transform it into HTML for web delivery, do you want us to become
> W3C members, too?")
>
>   
Yes, I agree that being TEI conformant for purposes other than 
interchange is a desirable goal. But designing an encoding scheme that 
fits every possible project's needs is a quixotic goal we never set 
ourselves. So there has to be room for compromise -- which is why we 
distinguish conformance/interoperable format from local practice.

>   
>>> * We will never have a conformant <soCalled>TEI Tite</soCalled> for
>>>   vendor use. 
>>>       
>> why not?
>>     
>
> The point of much of the syntactic sugar renaming in Tite is to
> reduce keystrokes. Requiring even a 1-character namespace prefix
> would negate any advantages.
>
>
>   
I don't get this. If you want 1 character tag names, don't use the TEI. 
Write your own schema, define a mapping between it and the TEI. You have 
attained conformance without confusing the TEI namespace. Next.

>
>
> Sure. The Imaginary Project creates a schema with half a dozen
> changes vs. vanilla TEI. Rather than expend the effort to figure out
> which things affected by the changes should be in tei: namespace and
> which should be in ip: namespace, they will just put every element
> and attribute affected by the change into the ip: namespace.
>
>
>   

There's no telling what foolishness some people will get up to. But I 
repeat -- what's your alternative proposal? If we are going to use 
namespaces at all, we must use them properly. No-one has yet proposed 
reversing the decision to define a TEI namespace. A namespace is, by 
definition, fixed, isn't it?
>>> He left me with a very insightful parting thought: "Boy, I hop e
>>> the Council doesn't make TEI into W3C Schema".
>>>   
>>>       
>> you'll have to gloss that a little further, too. did he mean
>> "make the TEI as Byzantine as Schema", or "make the TEI
>> use Schema"? if the former, its far too late, it already is :-}
>>     
>
> He meant the former, and he obviously does not think it is far too
> late. Nor do I, for that matter. I doubt you really do, either,
> Sebastian, as you understand TEI, but IIRC still have trouble
> wrapping your mind around W3C Schema (although you certainly do
> better than I with it :-)
>   

I don't see any sense in which we are making the TEI byzantine. We are 
making it a lot clearer what we mean and what the boundaries are.