[tei-council] MD chapter revised: namespace rules

[Sebastian Rahtz]

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.
> Some further thoughts. If we insist that TEI conformant documents
> follow draconian namespace rules, there are some pretty predictable
> potentially problematic probable consequences
>   
your nightmare scenarios are possible, I agree, but
not inevitable. Let's stop trying to second guess
what people will say, but publish a conformance
draft quickly and let them comment.
> * Most projects will not use TEI for document capture -- dealing with
>   those namespaces will just be too annoying. 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.
> * Many projects will not even bother to store their texts locally in
>   TEI, and will either abandon TEI conformance completely, or only
>   trot out the namesaced-conformant version for funding agencies and
>   blind interchange
>   
if they have a route to get conformant texts for when
it comes out of their vaults, sounds great. just
what the doctor ordered
> * We will never have a conformant <soCalled>TEI Tite</soCalled> for
>   vendor use. 
why not?

>
> I really think that this is an issue about which users should be
> canvassed before we commit to constraining conformance, as opposed to
> interchange format.
>   
agreed. if we can get the users to speak, rather
have just expose ourselves to another public
shouting match between Wendell and me....

> 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?
>
> I just asked a colleague what he thought of all this. He suggested a
> different likely pattern of behavior for users. He suggested that
> many users would tolerate the namespace business, but would not make
> the effort to, or not be able to, figure out which customizations are
> clean subsets and which are not, and thus would stick all
> customizations into their own namespace.
you'll have to expand that for me. can you give an example
of what you think he meant?
>  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 :-}
>
> P.S. As it applies to interchange format, as opposed to conformance,
>      I think I agree with the direction this thread is headed,
>      including that translated or renamed elements should be in
>      another namespace.
>   
I thought the opposite was agreed?

-- 
Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431