[tei-council] TEI Conformance

[Conal Tuohy]

I'd like to make 3 points about XML namespaces in TEI: the first 2 are
just about namespace URIs, the 3rd is about the use of namespaces
themselves:



1) We should allow any namespace URIs

I think there's general agreement now that names which are user-defined
extensions to the TEI core must not be in the TEI core namespace.
Similarly, it's clear to me that names which are distinct extensions
will require distinct namespaces. Anything else would be a recipe for
confusion.

But that's as far as I think we can go: I think the namespace URIs must
be left to the user. There are 2 reasons:

Syd's point that we should accommodate people's existing conventions
(and even IT infrastructure) for managing namespace URIs.

Many customisations will call on pre-existing XML vocabularies. We can't
pretend to define the namespace URIs of already-existing vocabularies,
yet I strongly believe that we should allow customisations which use
these vocabularies to be considered "conformant". e.g. I might make a
"graphical" customisation which (amongst other things) imports some SVG
elements, or an "ontological" customisation which introduces some RDF or
XTM vocabulary. 
http://www.w3.org/1999/02/22-rdf-syntax-ns#
http://www.topicMaps.org/xtm/1.0/
http://www.w3.org/2000/svg

In short, I think it's just infeasible to constrain the namespaces which
"conformant" TEI customisations may introduce (except that they must not
use the empty namespace or the TEI namespace). 



2) We need to responsibly manage namespace URIs which begin with
http://www.tei-c.org/

I agree with Syd's suggestion that it would be good to host custom ODD
specifications at www.tei-c.org, and I think the URLs of these ODD files
might (in some cases) make excellent namespace URIs for the extensions
which the ODDs define. However, it would surely also be sensible to host
ODDs for other types of customisation, too: customisations which don't
extend TEI but only constrain it further, or which introduce vocabulary
which already has a namespace URI. So incubation of a particular set of
TEI customisations ought to be independent of the namespaces used in
those customisations.

If the TEI-C endorses namespace URIs which begin with
"http://www.tei-c.org/" then we need to ensure that these URIs should
work (as URLs i.e. they should locate something, and not just return a
404), and they should continue to work. The 3 URLs I quoted earlier all
resolve to something useful - a schema, a specification, or a kind of
"splash" page. I know some people feel it's OK to use HTTP URLs which
fail to resolve at all (i.e. they return 404), which I find very odd. I
think it's due to a mistaken reading of the XML Namespaces spec[1] where
it says:

"The namespace name [i.e. the URI - Conal], to serve its intended
purpose, SHOULD have the characteristics of uniqueness and persistence.
It is not a goal that it be directly usable for retrieval of a schema
(if any exists). "

I think it's a mistaken to take this as a licence to use broken http
URLs. Whatever the XML Namespaces spec uses URIs for, it most definitely
IS a goal of the HTTP URI scheme that HTTP URIs should resolve. If
people don't want their namespace URI to resolve to something, they
should use a URN, not a URL! :-) NB the spec goes on to say:

"Uniform Resource Names [RFC2141] is an example of a syntax that is
designed with these goals in mind. However, it should be noted that
ordinary URLs can be managed in such a way as to achieve these same
goals."

In short, if we offer namespace URIs which begin with
"http://www.tei-c.org/" then we will need to manage them properly. 

[1] http://www.w3.org/TR/xml-names/#ns-decl



3) Attributes in TEI extensions will sometimes require namespaces too

It's very common (though not universal) in XML vocabularies that element
names are namespaced but attributes are not. It's certainly a
convenience. The idea is that you can disambiguate an attribute by
looking at qualified name of the element which contains it. e.g. in P5,
the TEI attribute "rend" is always found on elements which are in the
TEI namespace. Hence although the "rend" attribute itself has NO
namespace, it's intelligible from its context. By contrast the "xml:id"
and "xml:lang" attributes have been defined in the "xml" namespace
(whose URI is http://www.w3.org/XML/1998/namespace) because they can be
attached to elements in many different namespaces. The same applies for
rdf:about, xlink:href, xsl:use-attribute-sets, etc.

I think this implies that where a TEI customisation adds an attribute
which may be attached to an element in the TEI namespace, then we should
mandate that the attribute be defined in a namespace. Otherwise we have
a potential for different customisations to "collide". e.g. if 2
customisation modules declare an attribute called "foo" then the 2
modules cannot be safely merged.

On the other hand, if a customisation defines a new attribute only on
elements which are outside the TEI namespace, then a namespace could be
optional. 



Con