[tei-council] conformance draft

[Conal Tuohy]

Syd Bauman wrote:

> Four: namespace of new elements
> ----- --------- -- --- --------
> I am not at all sure it is a good idea that TEI require that new
> elements be in a separate namespace. I think that doing so
> * creates a higher barrier to actual use of the customization
>   mechanism
> * makes instances harder to read by humans
> * sends the wrong message politically -- that if you create a new
>   element, somehow you're not a member of the same TEI club
> for an extremely limited technical gain. 

I tend to disagree with all these points, actually, but for the moment I
will just make the strongest claim I can:

It is bad practice for the TEI Council to licence others to define new
names within the TEI namespace, under ANY circumstances.

Why do I think it's a bad idea to licence others to pollute the TEI
namespace?

Well, why do TEI elements use a namespace at all? The point of
namespaces is to "avoid clashes between names from different markup
vocabularies" ... "by assigning 'expanded names' to elements and
attributes".[1]

These "clashes" or "collisions" could otherwise occur in documents which
contain markup from multiple XML vocabularies, since the same name might
be defined in multiple vocabularies (e.g. "p" in TEI and HTML, "seg" in
TEI and DocBook). 

Let me first describe how namespaces work to avoid such collisions:

To distinguish similar names from distinct vocabularies, names are each
associated with a URI which identifies the vocabulary from which it is
drawn. e.g. TEI elements are associated with the TEI namespace URI
http://www.tei-c.org/ns/1.0 which is the name of the TEI vocabulary -
the "namespace URI" or "namespace name". 

Because URIs can be quite long, the XML namespaces specification
provided a way to use short prefixes in place of those URIs, and also
provided a way to specify a "default" namespace URI which can apply to
an entire document or a section of a document. Using a namespace prefix
or a "default" namespace is just shorthand syntax, though; the real
("expanded") name of a tei:p element is actually a pair of values: the
TEI namespace URI, and the "local" name "p":

{"http://www.tei-c.org/ns/1.0", "p"}

Whereas an html:p has an "expanded name" with a different namespace URI
and the same "local" name: 

{"http://www.w3.org/1999/xhtml/", "p"}.

Now, the reason that URIs were used to identify vocabularies was that
URIs are a globally distributed naming scheme in which anyone can easily
define a URI which is unique, and use that URI as the name of their
vocabulary. If vocabulary names were not unique, then we would still
have the problem of name collision, since e.g. we might call our
vocabulary "TEI", and the Tax Executives Institute might also define a
vocabulary with the same name. 

There can be no dispute as to who is responsible for the TEI namespace
URI "http://www.tei-c.org/ns/1.0" - it's owned by the TEI Consortium,
and it is up to us, the Council, to declare that it is the name of the
TEI vocabulary, and not the name of some OTHER vocabulary. If we say to
TEI encoders that they may use the "http://www.tei-c.org/ns/1.0" name to
identify OTHER vocabularies, then we have effectively negated the
purpose of using a namespace, because some "extension" vocabularies will
contain names which collide with names in other "extension"
vocabularies.

Now, do we want to avoid name collisions or don't we? If we don't care
about name collisions, what is the TEI namespace for? Why have we added
it? 

I don't see that using multiple namespaces in text encoding is really a
serious barrier, but if other people think it is, then we need to find
ways to help people use multiple namespaces, rather than pollute the TEI
namespace. In the meantime, if using multiple namespaces is too great a
barrier for some people, then they can use P4. P5 is namespaced, and
customisers should get used to it.

Cheers

Con



1. "Namespaces in XML 1.0 (Second Edition)" 
   http://www.w3.org/TR/REC-xml-names/#sec-intro