[tei-council] TEI Conformance

Dot Porter dporter at uky.edu
Tue Nov 28 10:33:29 EST 2006

On 11/28/06, Daniel O'Donnell <daniel.odonnell at uleth.ca> wrote:
> >
> > I was concerned because I'd taken the implication that customisations
> > using those *other* namespaces would be declared non-conformant
> > (because of e.g. not having "tei" in their namespace URIs).
> I guess I'm more of a fascist: Conformant status is something you step
> up to. You can be conformant but not TEI-certified Conformant if you do
> a number of things. But I don't see the problem with constraining the
> choices if you want the medal. We've been discussing raising the bar at
> the Board. (in a rush, so excuses).
Does this mean that my own extensions, <tei.dot:elements> would be
"TEI-certified Conformant," but if I want to incorporate SVG
(svg:elements), that would only be "conformant"? (and what is the
difference anyway?)

If we say that users *must* have tei in the namespace URIs, then don't
we risk them hacking existing schemas to create their own to guarantee
"TEI-certified Conformance" (whatever that means)? It seems to me much
more healthy to encourage users to incorporate other schemas if they
do what they need them to, even if the namespace URI doesn't include


> >
> > >> 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.
> >
> > > Yes, am I mistaken that attributes defaultly inherit the namespace of the
> > > element to which they are attached?
> >
> > I believe you are.
> >
> > <tei:element decls="#foo" xml:id="abc123" rng:something="blah"/>
> >
> > > Is an element in the tei namespace (however that is defined above), and has an
> > > attribute tei:decls, but the local-name prefix tei: is not needed because the
> > > namespace is inherited from the element it is on.  This also has two attributes
> > > in other namespaces.
> >
> > Strictly of course the namespace prefixes in your example are not bound to namespace URIs, but we can certainly guess the URIs you mean. e.g.
> >
> > <tei:element xml:id="abc123" xmlns:tei="http://www.tei-c.org/ns/1.0" decls="#foo"/>
> >
> > This is an element which has a "qualified name" of "tei:element". But this is just shorthand for its "expanded name" which is a combination of its "namespace name", which is "http://www.tei-c.org/ns/1.0" (not "tei", which is just the shorthand prefix), and its "local name", which is "element". The element has 2 attributes, one has a name in the "xml" namespace and the other (decls) is in NO namespace, or to put it another way, the decls attribute's namespace has the name "". That decls attribute is not in the TEI namespace, that is, the namespace formally known as "http://www.tei-c.org/ns/1.0"
> >
> > See http://www.w3.org/TR/REC-xml-names/#defaulting for details of namespace "inheriting".
> >
> > When the "tei" prefix is "bound" to the uri "http://www.tei-c.org/ns/1.0", that prefix may then be used  anywhere within that element (as an alias for "http://www.tei-c.org/ns/1.0"). So the "binding" between the prefix and the URI is inherited by child elements.
> >
> > However, child elements are not automatically in the same namespace as their parent - they must actually use the prefix in order to belong to the same namespace. In the example the "tei" which is bound to a prefix (such as the "tei:" prefix in your example) is not inherited by either child elements or attributes.
> >
> > With "default" namespaces it's slightly different.
> >
> > As an alternative to using a namespace prefix like "tei:", a namespace may be declared as the "default" namespace using the "xmlns" attribute, like so:
> >
> > <element xml:id="abc123" xmlns="http://www.tei-c.org/ns/1.0" decls="#foo"/>
> >
> > NB this is semantically identical to the earlier example.
> >
> > This is essentially equivalent to binding the namespace URI to the empty prefix. Any unprefixed elements then are interpreted as being in the default namespace.
> >
> > "Default" namespaces apply to the element on which they are declared and all its child elements. However default namespaces do not apply to attributes, only to elements. Hence the only attributes with defined namespaces are those which have explicit namespace prefixes. That's why, to correctly interpret the meaning of an attribute without a namespace prefix, you have to know the (qualified) name of the element which contains it.
> >
> > > Am I mistaken about that? It shouldn't be tei:decls="#foo" should it?!
> >
> > If we wanted to put all TEI-defined attributes in the TEI P5 namespace, yes we would have to write it like that. But I don't think we really want that do we? :-)
> >
> >
> > Cheers
> >
> > Con
> > _______________________________________________
> > tei-council mailing list
> > tei-council at lists.village.Virginia.EDU
> > http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> --
> Daniel Paul O'Donnell, PhD
> Department Chair and Associate Professor of English
> Director, Digital Medievalist Project http://www.digitalmedievalist.org/
> Chair, Text Encoding Initiative http://www.tei-c.org/
> Department of English
> University of Lethbridge
> Lethbridge AB T1K 3M4
> Vox +1 403 329-2377
> Fax +1 403 382-7191
> Email: daniel.odonnell at uleth.ca
> WWW: http://people.uleth.ca/~daniel.odonnell/
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Dot Porter, University of Kentucky
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu

More information about the tei-council mailing list