[tei-council] TEI Conformance

Tue Nov 28 14:29:26 EST 2006

On Tue, 2006-11-28 at 10:33 -0500, Dot Porter wrote: 
> 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
> "tei".

I mean that the TEI extension elements should be in a separate "tei
extension" namespace--independent of any other namespaces used in the
document. This would clearly indicate that "these elements have been
extended/added to/changed from TEI P5 in a conformant manner." It is a
step between "TEI extensions must be in the tei-namespace" (where we
started) and "TEI extensions must not be in the tei-namespace (but can
be anywhere else)."

As to the different types of conformance. As I said I was in a rush,
though Syd's comments are very useful (even as a bouncing off point):

> * conformance is like validity: either you are or you aren't

Yes and no. Really there are three things going on here (and always have
been): you can have validity (which is largely mechanical), and you can
interchangeability (again largely mechanical), and you can have
conformant (which is an intellectual claim and one that TEI has every
right to set standards for).

What I meant by the different levels of conformity can, starting with
Syd's distinction be labelled "interchangeable" and "conformant".
Interchangeable means, to me, anyway, the purely mechanical fact that a
given XML document can be understood without negotiation by somebody
else. This is a pretty low standard because it is purely
results-oriented. Presumably as long as it doesn't conflict with TEI and
is valid, we don't care what hacks I did to produce it. And, if there
are not conflicts, presumably I don't care what the TEI wants in terms
of namespaces anyway. In the P4 world, this would be equivalent to me
ignoring the extension mechanisms and successfully altering the main
dtds in a way that didn't actually cause anybody real issues at the
other end. An intellectually bad way of producing interchangeable texts.

"Conformant" is a different kettle of fish in my view. If I claim a text
is "TEI conformant" I am making a number of claims about both its
interchangeability and the process by which this interchangeability came
about. This means I am following the rules about extension, being
careful to avoid conflicts, and clearly marking out my extensions. If I
do this, then I can self-certify that my work is TEI Conformant. So
there is a certification mechanism, but it is a voluntary one in the
same way editors can submit editions to the MLA scholarly editions
committee for certification or I can post a little W3C valid emblem at
the bottom of my web pages. If I don't self-certify, that doesn't mean
my work is not TEI Conformant (though it also doesn't mean it is), it
just means I'm not claiming it is in the official way. In the same way,
not having the W3C emblem at the bottom of my webpage doesn't mean the
page is not valid, it just means I haven't asserted that it is.

So if TEI-Conformance is an intellectual claim of self-certification I
think we must set requirements for it. And my test for this all along
has been "either we are comfortable saying 'must'" or it is not
necessary for conformance". Conformant status in this regard can be seen
as a voluntary code of best practice. Anything else is merely (probably)
interchangeable.

> 
> * conformance must permit scholars to create their own, conformant,
>   arcane encodings for things we haven't thought of
> 
No problem here. But I think conformance does require that scholars tell
others where the TEI extensions are.
> 
> 
> * conformance should make it easy for scholars to do so

I would say that conformance should not be unnecessarily burdensome.
Like W3C valid status it is something that some will want to
self-certify and others won't care that much about. Interchangeability
should be easy to do; conformance should be something desired.

> 
> * it is very important that we continue to make efforts to lower the
>   barriers to TEI usage
> 
This is a different issue. The TEI is a system that people buy into the
significance of... or not. A way of lowering the barrier to TEI usage
would be to allow @type everywhere, for example, though we have reasons
why this is not a good idea. The goal is to find the balance between
meaningful standards and ease of use.
> 
> 
<snip>
> What is being discussed
> at http://www.tei-c.org.uk/wiki/index.php/Conformance is *not*
> conformance, but rather "degrees of interchangeability" or some such.
> 
I actually would reverse the nomenclature. "Conformance" is an
intellectual claim, which can have degrees. Interchangeability is a
technical claim that is either true or not. Conformant documents must be
interchangeable at a very minimum (which is why we don't want confusions
in the TEI namespace), but they must also be made interchangeable
following some specific practices and meet other standards.

> 
> Dot
> 
> 
> >
> > >
> > > >> 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
> >
> 
> 
-- 
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/