Meeting took place at the AFNOR offices in Paris, France. The workgroup would like to extend its thanks to both AFNOR for hosting the meeting, and to Laurent Romary for making the arrangements for them to do so.

Commenced ~13:17 on Mon; @ ~08:15 on Tue.

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

During the course of the one and a half day meeting, a variety of structures were renamed or changed. Throughout the rest of this document I will refer to the new names, even though in many cases the majority of discussion took place under the old names. chunk to specGrp (specification group) tagDoc to elementSpec classDoc to classSpec patternDoc to macroSpec schemaContent to content ident to ident Note also that tagDesc was not changed to elementDesc, but it seems it should be for consistency.

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

LB & SB both thought that atts of tagDesc needed to be able to express more possible combinations of attributes. After some discussion about the possibility of using a second attribute for inherited attributes, the following was agreed upon (note that the actual symbolic values were not intended to be carved in stone). * all attributes particular to this element (i.e., not the inherited attributes) ** all attributes, including inherited ones (i.e., null value) no attributes A B attributes A and B (whether inherited or not)

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.

From the user's perspective, the values of mode have the following meanings: add (default) The entire specification is part of the meaning of the module being defined (whether being defined initially or later by import). It is an error if there already is a specification of the same type of item (e.g. class, element, attribute of a given element, attribute value of a given attribute) with the same identifier. delete The specification which bears this attribute should be removed from its parent, as it were. I.e., valItems would be deleted from their valLists, attDefs from their attList, etc. It is an error if there is no specification of the same type of item (e.g. class, element, attribute of a given element, attribute value of a given attribute) with the same identifier. It is also an error if the element specifying deletion has children. RelaxNG is perfectly capable of enforcing this behavior, but expressing this co-occurrence constraint may not be possible using the current ODD language, and is not possible in DTDs or XSDs. In the compact syntax, this would look something like element macroSpec { attribute ident { xsd:NCName }, tei.global.attributes, ( ( attribute mode { "delete" } ) | ( attribute mode { "add" | "replace" | "change" }?, attribute type { "pe" | "epe" | "ge" | "dt" }?, xmlName*, equiv*, gloss?, desc, remarks?, ( string | content | publicID )+, refList? ) ) } replace The specification replaces the one with the same identifier. Semantically similar to a delete then an add. It is an error if there is no specification of the same type of item (e.g. class, element, attribute of a given element, attribute value of a given attribute) with the same identifier. change The children of the specification are added to (or replace if already present) the corresponding children of the definition being changed. Other aspects of the existing definition are left alone. It is an error if there is no specification of the same type of item (e.g. class, element, attribute of a given element, attribute value of a given attribute) with the same identifier. We did not address the issue of what to do with required children that are not being replaced or changed when mode is replace or change. We noted that the replace value cannot be dropped in favor of an explicit delete then add because that would require that there be two elements in a row when in some cases the content model permits only one.

From the processor's perspective, the values of mode have the following meanings: add (default) Create me if I do not exist (and this implies processing my new children in add mode). Raise an error if I do exist and am identifiable. delete Don't process me or my children (any new children supplied are erroneous). replace Leave me alone; process my new children in replace mode; don't process my old children. change Leave me alone and process my old and new children in change mode.

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 tagDescs 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.

datatypes Possibilities: use macroSpec define a new datatypeSpec express everything as per schema language

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.

Thus, to rename fs to French, one would have in a customization file something like: <module name="fs-fra" inherit="fs"> <elementSpec ident="fs" mode="change"> <xmlName xml:lang="fr">structureTraits</xmlName> </elementSpec> </module>

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.

We discussed several mechanisms and meanings of equiv, including XSLT code XPath expressions schema fragments just a name to correlate to another equiv which is inside the corresponding declaration.How to say bo is equivalent to <hi rend=bo>: <elementSpec ident="hi" mode="change"> <valList> <valItem ident="bold"> <desc>bold typography</desc> <equiv name="BOLD"/> </valItem> </valList> </elementSpec> <elementSpec ident="bo" mode="add"> <equiv name="BOLD" uri="http://www.bolds.com/bold"/> </elementSpec>