TEI META Task Force: Meeting Notes 22 Mar 2004 [MEM03]

ODD Language

Meeting opened with a presentation by LB on the current status of the TD chapter. During the presentation several issues came up and were either discussed briefly, tabled for later conversation, or discussed after the presentation.

Renames

<xmleg>

There was a brief discussion, without resolution, about whether or not the contents of <xmleg> were limited to the TEI example namespace (i.e., http://www.tei-c.org/ns/Examples/, in which case it should be <teiEg> instead) or not.

atts of <tagDesc>

Overrides

The issue of user overrides was discussed at length.

Long discussion about whether or not an override should need to specify the module in which the element being overridden was declared.

LR argues that the user-level override mechanism should be parallel or equivalent to the module creation mechanism. I believe all were swayed in principle by his argument. There was some skepticism about its practicality.

The initial question was whether <moduleRef> overrides should be via content of <moduleRef> , pointing to a <specGrp> , a separate element, or what.

We easily decided that if we were to keep the current ‘attribute of <moduleRef> points to a <specGrp> of overrides’ that the attribute should be named overriddenBy (as opposed to override).

However, after significant discussion we concluded that user overrides should be specified essentially the same way any other specification is made, except that an attribute (mode) indicates whether the current specification is to be added to or removed from the module currently being defined, or to replace or modify the current definitions therein.

This new mode attribute will be available on all the elements used to define elements & attributes. A complete list was never explicitly spelled out at the meeting, but we operated on the presumption the list included <elementSpec> , <classSpec> , <macroSpec> , <content> , <refList> , <attList> , <attDef> , <valList> , <valItem> , <exemplumList> , and <classes> ; also <gloss> , <desc> , and <remarks> , when they occur as children of <attDef> , <elementSpec> , <macroSpec> , or <classSpec> . Although it was never explicitly mentioned at the meeting, obviously these need to be put into a new attribute class for the purpose.

We agreed that mode affects only ‘identifiable’ elements, which we defined as those that bear an ident attribute or those that are single children (i.e., not allowed to repeat, and thus it could be unambiguously determined which one was the intended target) of one that does bear an ident attribute.

On Naming

What used to be <ident> and is now ident is part of the TEI abstract model, not the implementation language, or an instantiation in a given language. Note that we explicitly consider an ident to be a particular kind of name (semantically, one that uniquely identifies a structure in the TEI abstract model; syntactically one that is NAME ala XML) or <name> (which, in turn, is a particular kind of <rs> ).

LR discussed the differences among classifying (‘Zooloo’), coding (‘ZL’), and naming (‘Zulu’ in EN). This had significant implications during our discussion on internationalization.

Reference List

A suggestion was made to drop <ptr> from content of <elementSpec> and generate complete list of all <tagDesc> s that point to this element.

By meetings' end, after significant discussion, we concluded that the <ptr> (or <xptr> , but remember, that is an element likely to disappear) elements should stay, but should be grouped in a <refList> .

Odds & Ends

LR noted that <desc> cannot be treated independently of <equiv> .

We briefly discussed the notion of reversing the direction of module containment declaration. I.e., the idea that each element declares what class(es) it is in, why not have the elements declare what module it is in, too?

It was reported that during a pre-meeting conversation it was decided that the ODD syntax should allow for alternation of attributes within an ATTLIST. (I.e., when schema language permits the constraint, being able to say ‘either this attribute or that attribute, but not both’.) There was implicit consensus on this issue. LB reported that it had already been implemented.

There is an open question of whether type of <classSpec> is required.

Internationalization

AB presented some of the issues.

Question of whether or not AB's language identification for instances question is the same as an instance identifying its schema.

We agreed that renaming is not the same as equivalency, and that each <*Spec> should have zero or one <xmlName> elements (we did not use normal <name> elements because the content is far more constrained), which the customization files could of course change.

It was noted that Roma could (easily) produce a stylesheet that could be used to change a document instance that was encoded in, say, Spanish to the canonical form.

Appendix B:

My notes have the sentence ‘Distinguish the import schema mechanism and the reference some documentation mechanism.’ Anyone know what this means?