ODD Development Working Group DH2012 Meeting Summary

Issues discussed and resolutions:

• Durand Conundrum:
  • Explanation: TEI ODD uses its own language for documenting meta-schemas, but an undocumented subset of RelaxNG for detailing its content models (of elements and datatypes), and the conundrum questions why not do it all in RELAX NG, or all in TEI. The hybrid nature of this imposes certain limitations, but does potentially simplify processing when generating RelaxNG.
  • Discussion: A wide ranging discussion took place arguing the merits of using a single system (e.g. TEI) vs drawbacks of reimplementation of well known and existing standards (e.g. RELAX NG). It was suggested that we usually try not to reimplment other standards that we use (such as XPath). Nonetheless many benefits (e.g. easier co-occurence constraints, the ability to document intentions not necessarily be able to be modelled in any current schema language, the intentional nature of being an meta-schema abstraction, etc.) Developing ODD in this way would not necessarily break backwards compatibility (but switching to using another schema language entirely, like RelaxNG would).
  • Resolution: The general (though not unanimous) consensus at the meeting was that resolving the Durand Conundrum by moving to a wholly TEI ODD meta-language was a beneficial move for the TEI, but that this has significant resource implications for ODD processing. It was noted that we need a better test suite, clear and detailed language specification, a documented ODD processing model, and more devolved community implementation.
• Crystal Maze:
  • Explanation: Laurent Romary (via Skype, and previous presentations) detailed his theory of re-usable bits of customisation and content models called ‘crystals’.
  • Discussion: Some felt that slightly extended use of <specGrp> and <specGrpRef> would enable this, and Sebastian Rahtz attempted to document an method using this. It was noted that context/scope of the crystal and subsequent modifications to it may cause problems.
  • Resolution: The general consensus was that this was a good idea, but may already be implementable with only a few changes assuming the existence of a library structure for such crystals. It needs more concrete uses cases and attempts a formalisation. Laurent Romary to be encouraged to try the existing mechanisms. The suggestion of a @context taking multiple XPaths should also be investigated (whether or not it is implementable in RelaxNG).
• Module inter-dependency:
  • Explanation: In some cases elements in one TEI module (A) require that another TEI module (B) is loaded because the content models of an element in A directly requirpes something that is defined in B (e.g. a class or element) but no method exists to indicate this module inter-dependency.
  • Discussion: The discussion focussed on the nature of modules, and the reasons for such inter-dependency. It was noted that at the time of the meeting there were almost 500 direct references to elements in content models.
  • Resolution: It was felt that this should not be handled separately from the cutting the Gordian Knot of the Durand Conundrum. That is, in reassessing how the TEI implements its content models, if the content model of an element really requires the existence of an element from another module it should have a way of documenting this (or whether that element is optional, etc.). Leave well enough alone for now.
• Cardinality and Model Classes:
  • Explanation: Bertrand Gaiffe presented a problem of cardinality of model classes and suggests that when elements content models include should cardinality be expressed.
  • Discussion: There was a variety of discussion about whether this should be done in the class itself or in the content model. <memberOf key=”model.duckLike” minOccurs=”1” maxOccurs=”3”/> <classRef key=”model.duckLike” minOccurs=”1” maxOccurs=”3”/> Bertrand detailed some minor changes he made to enable his approach in ODD.
  • Resolution: The consensus that the idea was a good one and adding cardinality is desirable. It was noted that if a variant of Lou’s solution to the Durand Conundrum was accepted, then it should be included as a possiblity for this.
• Local Attribute Customisation:
  • Explanation: The ability to customise the desc, valList, and other aspects of an attribute inherited from a class on a per-element basis. For example giving different suggested values for @type on an element, or a more specific description of an attribute when used on a certain element.
  • Discussion: This had been agreed by the TEI Technical Council already as http://purl.org/tei/fr/3415801 but had not yet been implement.
  • Resolution: Implemented by Sebastian, but needs more testing and documentation, as well as use throughout the TEI system.
• Areas of ODD2 which are not well defined:
  • Discussion:There was a variety of topics were discussed on aspects of ODD2 which are not well defined. This included the processing model, the order of processing and deletions, need for a defined test suite, whether different processors can produce differing output, requirements for output, documentation generation, ODD processing settings.
  • Resolution: No specific resolutions were reached, except the consensus that these were all important areas especially if ODD was to evolve further.
• ODD-processing which is unimplemented at time of meeting:
  • Discussion: A variety of topics were discussed that were unimplemented at the time of the meeting, including the chaining of ODDs (now partly implemented but needing more testing), declaring an object then customising it straight away, whether native XSD generation is needed.
  • Resolution: No specific resolutions were reached, except the consensus that chaining ODDs should be implemented, and instant modifications desirable. There was less desire for native XSD generation.
• Problems which do not seem amenable to ODD as it stands and need a new version:
  • Discussion: A variety of topics were re-traced which seemed to imply a new version of ODD such as solving the Durand Conundrum, subclassing, attribute/element interdependency, alternation of attribute/element, whether schematron-like constraints should also be reinvented, other flawed ideas for shortcutting content models.
  • Resolution: The same conclusion concerning the Durand Conundrum as reach above; subclassing is desirable and possibly supportable with Laurent’s crystals, and more expressive attribute/element relationships should probably be done in schematron. Shortcut content models were considered a bad idea, and the Burnard Resolution (to the Durand Conundrum) was seen as a better solution
• Funding Priorities in order of perceived prioirity:
  • New ODD Editor
  • Separate ODD Processor Implementation
  • Group-writing grant application: It was agreed good idea for TEI community members to put in a bid for rewritting Roma, but with a backdoor workpackage on modifying the underlying language
• Other
  • How can we improve support/training/community/ODD collections?
    • A variety of ways to improve support, training, and awareness of ODD were discussed. We should strive to make the common and easy things very easy for users to do.
  • Visualization
    • Ways to visualize differences between ODDs were discussed and see results of customisations in a visual but intuitive and understandable method. Encouraging community developments in this area was seen as a good thing.
  • Combining multiple ODDs, pieces of customisations (e.g. Laurent’s Crystals)

Various other topics were discussed but were not central to the meeting. See tcw26a.xml for more.