[tei-council] TEI Conformance
Christian Wittern
wittern at kanji.zinbun.kyoto-u.ac.jp
Tue Nov 28 06:57:20 EST 2006
"Conal Tuohy" <Conal.Tuohy at vuw.ac.nz> writes:
> 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
>
> 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).
But these are different XML vocabularies, not user extensions of the
TEI? I thought our discussion was about what namespace to use for
elements and attributes (re)defined using the ODD mechanism. For
existing vocabularies, you would typically just pull in the schema
file into your own extension, but not add a new namespace to them?
> 2) We need to responsibly manage namespace URIs which begin with
> http://www.tei-c.org/
And since I see not compelling reason for going into this business, I
think this is a bad idea. Thus for me the compromise of having users
define their own namespace string, but give a nod to TEI seems a good
solution. We could of course say *should* use the letters tei
somewhere, not *must*.
> 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.
Right, we should think about attributes as well. I think it should be
mandated to use a full qualified name if the NS of the attribute is
different from that one of the element, which I think is in fact
common practice.
All the best,
Christian
--
Christian Wittern
Institute for Research in Humanities, Kyoto University
47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
More information about the tei-council
mailing list