[tei-council] MD chapter revised: namespace rules

[Syd Bauman]

> I think this is a matter of roses smelling as sweet by any other
> name. If all the draconian prose moves to "interchange", fine; but
> in that case, just quietly lose the "conformance" chapter entirely.
> 
> Let's not have *two* distinct barriers, or one so low ("if you want
> to be TEI conformant, BE GOOD") that it doesn't merit more than a
> paragraph of text.
> 
> As far as I am concerned, you can either be inspired by the TEI, or
> conform to the TEI. Call that "interchangeable with the TEI" if
> preferred.

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.


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. (Mind you, I'm not saying we
made a mistake in doing so -- given the technology of the day I'm not
sure there was much other choice.)


The barrier to proper customization of P5, although a *lot* better
than with P4 (thanks in large part to you, Sebastian), is still
pretty high. 


> >   E.g., imagine the project that expected to capture TEI P5 texts
> >   using a customization that replaced <choice> with the old Janus
> >   attributes (because they know they are dealing with only 1
> >   language and have no characters out of Unicode), and want to
> >   change xml:id= to id= and target= to an IDREF attribute for
> >   capture so that their XML editor will do the right thing.
> sounds like they won't be conformant, poor people.

That's my point. This is the very kind of customization we have been
telling people they could do, or might even be available directly
from the TEI as an example ODD or some such, all along. People liked
the idea.


> if they have a route to get conformant texts for when it comes out
> of their vaults, sounds great. just what the doctor ordered

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


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


> > This may not be easy. For example, roma will need to know that
> > changing an attribute from data.numeric to data.count is a clean
> > change, but from data.name to data.word is not. (There are things
> > we may not be able to expect roma to do, of course, like read
> > users' regular expressions and figure out if it represents a
> > clean subset of a datatype or not.)
> >   
> you could implement some of this with a free-standing
> TEI conformance checked for an ODD?

Well, yes, but my point was
a) it should be integrated into roma / webRoma;
b) it isn't easy.


> you'll have to expand that for me. can you give an example of what
> you think he meant?

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.


> > He left me with a very insightful parting thought: "Boy, I hope
> > 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 :-)