[tei-council] MD chapter revised: namespace rules

Tue Apr 10 11:02:10 EDT 2007

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.

Like everybody else, I'm having trouble with simple project-based
renamings, since they can remain in the TEI namespace under principle 3.
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.

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. We don't want
translations by implication or practice to be or be seen as
substantively different from the standard in anyway. Perhaps the way to
see this is that "renaming" and "translation" are not exactly the same
thing: a "renaming" may involve less than all the element names and may
occur with other extensions and additions; a "translation" involves the
entire standard and may not involve other additions and extensions.
Renamed elements remain in the TEI space from which they have been
renamed; translations are given a (sub) TEI namespace of their own to
indicate that they are 1:1 but may have name conflicts with the standard
names. Individuals and projects can rename, extend, or otherwise modify
translations, subject to the same rules about names spaces that apply to
modifications of the standard as long as we replace "tei namespace" with
the name of the specific translation.

Finally a question: what happens if I extend a tei attribute to a new
element (or make it global).

In this case it seems to me that the "extended" attributes have to go in
a different namespace; but I'm not sure about the "original"
tei:namespaced attributes: presumably I'm extending the element because
I want additional elements to share the attribute with original tei
elements. I'm leaning towards saying that the "original" tei attribute
has also changed in this case. Or in other words: if I make @type
global, I am actually removing tei:type from the elements on which it is
found and replacing it with mynamespace:type throughout the whole tei.

-dan

On Tue, 2007-10-04 at 08:57 -0400, Dot Porter wrote:
> I also agree with James on points 1, 2, and 3. I'm on the fence on
> point 4 - whether renamed elements should be in a different namespace
> - but I think Lou makes a very good point about name collision which
> has me leaning towards renaming = different namespace. It's a little
> more work up front, perhaps, but would save a lot of headache in the
> long run.
> 
> Dot
> 
> On 4/10/07, Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> wrote:
> > James Cummings wrote:
> > > Lou Burnard wrote:
> > >> Inter alia, and as a straw man, I'd like to propose for discussion the
> > >> following draconian rules about the use of namespaces in modification:
> > >>
> > >> 1. New elements may not be placed in the TEI namespace
> > >
> > > I can agree with that, though we may disagree on what is a 'new' element.
> >
> > By "new" I mean an element not already defined by the Guidelines. What
> > fiendishly cunning other case do you have in mind Dr Cummings?
> >
> > >
> > >> 2. If new attributes are added to a TEI element, the resulting element
> > >> must be moved out of the TEI namespace.
> > >
> > > I'm not convinced by that.  If I add a new attribute to a TEI element, the
> > > TEI element is still a TEI element.  It just has a new attribute and that
> > > attribute is signalled as not being part of the TEI by itself being in a
> > > different namespace.  my:newAtt="foo".  I don't see that the element is now
> > > so changed that it is no longer the TEI element.
> >
> >
> > OK, this is a plausible argument and I am disposed to agree with you.
> >
> > >
> > >> 3. Only modified elements which have undergone a clean modification [1]
> > >> may remain in the TEI namespace.
> > >
> > > Agreed, but I think adding an attribute which is in a different namespace
> > > is a clean modification.
> >
> > Yes, though only if I agree with you on (2) above.
> >
> >    You are right that changed content models, etc.
> > > are dirty changes.  However, if the change is to remove an element from
> > > some classes, or limit an open attribute value list, or anything similar
> > > which constrains it, then that is a clean modification because the TEI
> > > content still validates against tei_all.
> > >
> >
> > Yes. The draft does try to make this distinction clear.
> >
> >
> > >> 4. If a TEI element is renamed, it may not remain in the TEI namespace,
> > >> except that TEI namespaces are defined for systematic renaming of TEI
> > >> elements into different languages.
> > >
> > > I'm still not convinced that TEI translations need separate namespaces.
> >
> > Well, let us wait for reactions from others, because I currently still
> > think that separate namespaces for separate translations makes a whole
> > lot of sense, organizationally, politically, and technically. If we dont
> > do that, then every new translation has to watch out for name collision
> > with every other language now and in the future! I am less sure about
> > individual renamings, but still feel that basically if you don't use the
> > names we have chosen for our elements, whether or not you make explicit
> > the relationship between your name and ours, you are polluting the TEI
> > namespace. And you have all the headaches about name collision. And my
> > dimwitted TEI application has to go and read the ODD every time it
> > processes a document to know what to do with your renaming.
> >
> >
> >
> > > They should be conformant according to the Renaming Subset schema.  If
> > > something is simply a renamed element/attribute and it otherwise is
> > > identical to the TEI original (and documented with ODD/equiv) then I do not
> > > feel it needs to be in a different namespace.  It is, for all intents and
> > > purposes, the TEI element.  If I have <div type="chapter"> and instead
> > > rename this <chapter> keeping everything else the same, does this really
> > > need a new namespace?  The original view of the Renaming Subset was that it
> > > didn't.
> >
> >
> > I'm happy with the concept of a renaming subset schema. I just think it
> > ought to use a different namespace for the renamed elements.
> >
> > >
> > >> [1]A  "clean" modification is defined in chapter MD as one which results
> > >> in a schema that matches a proper subset of the documents matched by an
> > >> unmodified schema.
> > >
> > > I think clean should include reversal of renamings, and that translations
> > > are just a specialised form of renamings.
> > >
> >
> > I think adding this level of complexity may be just a level too far for
> > many simple-minded processors.  But, as I said, let's wait to see what
> > others think.
> >
> >
> > >> Comments? Alternative proposals?
> > >
> > > Alternative proposal:
> > > 1. Entirely new elements should be in a new namespace
> > yes
> >
> > > 2. Renamed elements, properly documented should remain in TEI namespace
> > no
> >
> > > 3. Translations are just a form of renaming.
> > yes, except that they are systematic
> >
> > > 4. Adding new (namespaced) attributes to a TEI element, does not stop that
> > > TEI element being TEI.
> > yes
> >
> > > 5. Our definition of 'clean' modification should include renamings.
> > >
> >
> > no!
> >
> >
> >
> >
> > _______________________________________________
> > 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/