[tei-council] MD chapter revised: namespace rules

Conal Tuohy Conal.Tuohy at vuw.ac.nz
Tue Apr 10 16:43:33 EDT 2007


For the record I am with Lou 100%. 

I think TEI-processing software can safely ignore attributes which it does not understand. 

Regarding translation and renaming in general, it's clear to me that a new namespace must be used whenever a name is changed, for whatever reason. Otherwise I will change <text> to <chapter> and you will change <div> to <chapter>, and we will have the potential for confusion. Or 2 languages will have the same word meaning 2 different things, and again we have a confusion.

On a positive note, distinct XML namespaces should actually help to clarify the distinction between the distinct vocabularies, and allow for simple transformation mechanisms (for canonicalisation into TEI interchange form).

Con


-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU on behalf of Dot Porter
Sent: Wed 11/04/07 0:57
To: Lou Burnard
Cc: TEI Council; James.Cummings at oucs.ox.ac.uk
Subject: Re: [tei-council] MD chapter revised: namespace rules
 
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
>


-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************
_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council




More information about the tei-council mailing list