[tei-council] TEI Conformance

[Conal Tuohy]

> Conal Tuohy wrote:
> >> 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). 

James Cummings wrote:

> So is it the case that in order to be TEI Conformant all 
> elements and attributes 
> must be namespaced?  Id est, all elements and attributes are 
> either in the TEI 
> namespace, the XML namespace, or some-other-namespace.

That was just a suggestion from me, I think. I don't think your original
proposal was quite so stern? 

It's a question of how strict we should be. 

For sure, we should not give an imprimatur of "conformance" to
user-extensions which add new names to the TEI P5 namespace. But should
we go beyond the demand "don't pollute the TEI namespace!"? I don't want
to be over-prescriptive, but I think extensions should use XML
namespaces where it it's necessary to disambiguate their vocabulary from
other vocabularies, and I think extensions which don't take the minimum
steps required to do this should not be labelled conformant.

However, I wouldn't go so far as prescribing that ALL attributes be in a
namespace, though I think we SHOULD prescribe that all new elements must
be. That would make David's example non-conformant.

Essentially I'm suggesting the same rules as the W3C define for XSLT.
See http://www.w3.org/TR/xslt#xslt-namespace where it gives this general
rule: "Vendors must not extend the XSLT namespace with additional
elements or attributes. Instead, any extension must be in a separate
namespace. " and follows up with: "An element from the XSLT namespace
may have any attribute not from the XSLT namespace, provided that the
expanded-name of the attribute has a non-null namespace URI. " and
equivalently "It is an error for an element from the XSLT namespace to
have attributes with expanded-names that have null namespace URIs (i.e.
attributes with unprefixed names) other than attributes defined for the
element in this document.[i.e. the XSLT specification document - Con]"

So according to these constraints the following example would be
non-conformant because "foo" has been illegally added to the TEI
namespace:

<TEI xmlns="http://www.tei-c.org/ns/1.0">
	<foo/>
	...
</TEI>

This would be non-conformant because "foo" is not in any namespace (i.e.
its namespace URI is null):

<TEI xmlns="http://www.tei-c.org/ns/1.0">
	<foo xmlns=""/>
	...
</TEI>

This could be conformant because "foo" is in a namespace called
"http://foo.org/ns/foo".

<TEI xmlns="http://www.tei-c.org/ns/1.0">
	<foo xmlns="http://foo.org/ns/foo"/>
	...
</TEI>

This would be OK, too, even though "flavour" is not in a namespace,
assuming that the schema allowed the "flavour" attribute only on
elements which were introduced in the extension schema. 

<TEI xmlns="http://www.tei-c.org/ns/1.0">
	<foo xmlns="http://foo.org/ns/foo" flavour="chocolate"/>
	...
</TEI>

This, however, would be non-conformant, because the flavour attribute
has no namespace AND has been allowed on an element in the TEI
namespace.

<TEI xmlns="http://www.tei-c.org/ns/1.0" flavour="chocolate">
	<foo xmlns="http://foo.org/ns/foo"/>
	...
</TEI>

A conformant example would have to define such a "global" flavour
attribute in a namespace ("http://gastronomy.com/ns/"):

<TEI xmlns="http://www.tei-c.org/ns/1.0"
xmlns:gastro="http://gastronomy.com/ns/" gastro:flavour="chocolate">
	<foo xmlns="http://foo.org/ns/foo"/>
	...
</TEI>

> >> But these are different XML vocabularies, not user 
> extensions of the
> >> TEI?  
> > Aren't they both? As I see it, they would (foreign) 
> vocabularies which
> > some user has used to extend the TEI vocabulary.
> 
> I might be splitting hairs here (better than splitting 
> hares), but they are 
> different in some respects.  In one a user has taken an 
> existing vocabulary and 
> decided that it works better than the TEI provision in this 
> area.  In the other 
> case they have decided that neither the TEI nor any other 
> standard they know 
> about handle this well enough and they must invent new 
> elements.  So in the 
> first they import an existing standard not intended for use 
> with TEI documents 
> and apply it (or part of it?) to some portion of an otherwise 
> TEI document.  In 
> the second they build out from the TEI and add new elements 
> where the TEI 
> doesn't have them.  Although I understand that they are both foreign 
> vocabularies from a TEI perspective, they have got there 
> through very different 
> routes.

Yes ... though really it's just the perennial issue in software
development of whether to build something new or to re-use. Users will
extend TEI (building something new) but some of their building materials
may exist in prefabricated form. 

To re-use a vocabulary doesn't necessarily require inclusion of an
external schema. A TEI ODD can use <elementSpec> etc to explicitly
define elements whose names are drawn from an existing namespace (which
may or may not be already defined in some other, "canonical", schema).
Sebastian's customisation manual gives an "amusing" example of this
approach, which adds XInclude vocabulary to TEI.

> > I can think of cases where one would want to write one's 
> own (TEI ODD)
> > schema for an extension which uses another, pre-existing, 
> namespace. For
> > instance, one might define a TEI schema which includes some date
> > elements from the Qualified Dublin Core namespace
> > http://purl.org/dc/elements/1.1/, such as dateCopyrighted,
> > dateSubmitted, or whatever, without wanting to import all 
> the DC types,
> > and while actually constraining those elements further than the
> > Qualified DC schema
> > http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd does.
> 
> Do, or should, we have any recommendations concerning the use 
> of other 
> namespaces in this way?  Should we be saying that if you use 
> another existing 
> namespace you should use its schema as it intended? (I think 
> the answer is No, 
> we shouldn't say this).

I agree - and in fact I don't think we even CAN say that, because a
namespace doesn't necessarily HAVE a schema of its own. A namespace may
be used in zero or more schemas, and there's not necessarily a
"canonical" schema for a namespace (or vice versa, either). For
instance, the XSLT namespace ("http://www.w3.org/1999/XSL/Transform") is
used in XSLT 1 and also XSLT 2, which are distinct markup languages (and
neither of which, AFAIK, even HAVE normative machine-readable schemas!)

I think it's important to be clear that namespaces and schemas are
really quite distinct things. A schema defines a language, whereas a
namespace is a label for a vocabulary. A language may use any number of
vocabularies, and conversely the same vocabulary may appear in multiple
languages.

Cheers

Con