[tei-council] MD chapter revised: namespace rules

Wittern Christian cwittern at gmail.com
Tue Apr 10 21:13:18 EDT 2007


Dan O'Donnell wrote:
> It seems to me that we can refine the set of principles:
>
> 1. New elements may not be placed in the TEI namespace.
> 3. Only modified elements which have undergone a clean modification may
> remain in the TEI namespace. The addition of attributes to a TEI element
> is clean as long as the new attribute itself is identified as coming
> from a different namespace.
> 4. Official translations have their own TEI namespace as long as they
> represent a 1:1 translation of the entire standard and remain
> up-to-date.
>
>   
This is what I would agree to as well.

> Like everybody else, I'm having trouble with simple project-based
> renamings, since they can remain in the TEI namespace under principle 3.
>   
I do not have a problem here.   For interchange, it would be a matter of 
courtesy to restore the original TEI form.

> The same is also true of translations if you see them as being in
> essence renamings (about which more below), since they should also be
> clean--though I can see the practical and political argument in favour
> of using distinct (sub) namespaces for official translations as long as
> they reflect a complete, up-to-date, and 1:1 translation of the
> standard.
>   
It might be better just to indicate the "valid as of" date.

> I think my own leaning is that the clean modification principle 3 is
> key. The use of the TEI namespace says: "I am identical to or have been
> cleanly modified from the TEI standard; you can process me with the
> assurance that you understand what I am"--i.e. the question of whether
> something stays in the namespace is not only a negative decision
> identifying elements that have diverged from the standard, but a
> positive one identifying elements that have not. So under this, cleanly
> renamed elements would remain in the namespace, even if that adds a
> processing cost in figuring out what they are an alias of. Of course the
> addition of a processing cost is an argument against renaming elements
> for interchange that projects might want to pay attention to. Avoiding
> conflicts is the responsibility of the renamer, and a conflicting name
> is not a clean modification IMO (except for translations of the entire
> standard, see below).
>
> If we take the view that the TEI namespace is a positive assertion, then
> translations are a bit of an issue: presumably they are by definition
> clean modifications (except that unlike modifications of individual
> elements, there is always the possibility that individual translated
> elements might conflict with English language ones), in which case they
> should under principle 3 be in the TEI namespace. 
Translations *are* in a TEI namespace, just a different one from the 
canonical TEI.

All the best,

Christian





More information about the tei-council mailing list