[tei-council] TEI Conformance

[Dan O'Donnell]

I'm trying to catch up on where we are with this. From what I've been
seeing, my sense is that the namespace issue actually is relatively
important in conformance, no?

If so, do we have a consensus that we need to do something about it in
determining conformance rules or are we still thinking we should be
leaving it to one side?

I like the idea of taking the W3C specification Conal cites, mutatis
mutandis. The only addition I would make comes back to the idea of TEI
extensions. These seem to me to be neither fish nor fowl in the W3C
formulation. One the one hand we, like they, do not want to polute the
TEI P5 namespace; but extending the TEI using the provided mechanisms is
not the same thing as simply using a different name space. So how about
something like this:


> TEI P5 Conformant Documents must not extend the TEI P5 namespace with
> additional elements or attributes. Extensions to the namespace may be
> added in one of two ways. Extensions formulated according to the
> procedures outlined in the Guidelines must appear in a distinct TEI
> Extension namespace. All other extensions must appear in an
> appropriate namespace. An element from the TEI P5 namespace
> may have any attribute not from the TEI P5 namespace, provided that
> the expanded-name of the attribute has a non-null namespace URI. It is
> an error for an element from the TEI P5 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 the P5 Guidelines.

On Tue, 2006-05-12 at 11:43 +1300, Conal Tuohy wrote:
> > 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
> _______________________________________________
> 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
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/