ODD Development Working Group DH2012 Meeting Notes

• TEI ODD uses a subset of RelaxNG, but we don’t document what that subset contains
• Some things hard to express: e.g. non-deterministic content models
• “If you are going to use RelaxNG to express content models, why not use RelaxNG for everything?” (Or W3C Schema, etc.)
• One way to resolve: Yup, do everything in RelaxNG.
• Another way: reinvent RelaxNG subset in TEI ODD
• RelaxNG also used for datatypes, not just content models
• Implement as TEI: possibly use existing elementRef/classRef/moduleRef in more general way (and with min/max/etc.)
• classRef with new attribute to say whether it is repeatable, etc.
• new elements for sequence optional, alternation, etc.
• And need a way to say ‘there is a text node here”.. what is difference between this and any other datatype?
• Can anyone explain what ODD can do that RelaxNG can’t do? Only argument is really if ODD is more expressive or seriously easier to use. Using islands of relaxNG with ODD means not full-blown RelaxNG and so it protects you. Buys you clarity and possibility for more user-friendly ways. Novice TEI users need to learn _another_ language. (But that could be good for them.) Same concepts have to be learned. Tool support better for RelaxNG, we shouldn’t isolate TEI. Would need very precise guidelines of TEI’s use of RelaxNG. Would still need extra step of assembling documentation from the RelaxNG. RelaxNG designed as schema language and customisation, not as much as a documentation language. “The problem with schema languages is there are more than one.” With ODD you aren’t just documenting the structure (etc.) but the underlying ontology of the TEI Abstract model (and could generate a very different schema technology).
• Schematron another example of escaping into islands of another language; Some parts of the Guidelines are just recommendations in prose not expressible in RelaxNG. So even when generating output will still need it.
• Using ODD is much more user-focussed, implementation independent view of conceptual model. An abstraction.
• Co-occurrence constraints like in Syd’s presentation are good argument for having it in one language.
• We won’t reimplement all sorts of things which are minor standard aspects (xpath, regexes, etc.) as there are different layers for different purposes.
  • But (as stefan argues) that there are multiple ways to do the same thing (ODD/RelaxNG/Schematron)
• MEI uses some conditional statements, and so sees no problem using schematron.
• Can express co-occurrence constraints in current ODD by doing what is currently tag abuse. Let’s formalise that abuse to make it accepted.
• If we decided to completely reverse the TEI and implement in RelaxNG, it would take lots and lots of time. (Should that be factored in?) All schema languages fail to provide good methods for consistent regular documentation. If we believe in literate programming then turning it on its head probably a bad idea.
• There are proponents of different schema languages, thus we’ll be a meta-schema you can generate your preferred one. Not just a language of its own for no reason, it is an intentional abstraction. W3C/RelaxNG overlap and ODD expresses that overlap. It produces and manages the intersection between these schema languages. But you can do wonderful things in ODD that you can’t in these schema languages, mostly in documentation.
• RelaxNG: Bit of documentation, bit of schema, bit of documentation, bit of schema? Documentation only linked to the element specification by ‘neighbourliness’.
  • c.f. DocBook doesn’t have much of notion of customisation other than on the module level
• If we constrain the language we can help with ODD customisation to warn about conformance at level of content models
• Although TEI is mostly aimed at DH audience, ODD is used by others who want to create markup languages. If we had more rigorous specification/test suite/etc. that would help those.
• Re-expressing everything in ODD might fill a lacuna of a documentation/schema language, in the same way xptr/XPointer did.
• ODD as a high-level language that we’re compiling into a slightly lower level language. This compiling is always the case as the tools that use RelaxNG are doing something similar.
• Would DocBook use ODD if we updated it?
• Conceptually your customisations of the TEI we can analyse as an object in itself.
• We might want to express things in ODD which aren’t able to be done in any individual schema language, so tying ourselves to any individual one a bad idea? e.g. stand-off annotation, constrain annotation segments to particular places in the document
• Would be good to get a better sense of where the payoffs are down the road. Closing the loophole not that much of a payoff. It is in user-focussed, education, learning of TEI. Cost, is more moving the TEI into a world that relies on our own community’s tools/implementations.
• BB: From user perspective schematron is what I’d like to get rid of;
• <content> wouldn’t contain this new markup? Currently macro.schemaPattern, relaxNG. Proposing to invent new element which is a new alternative.
• Better test suite, better, clearer, processing model, means not just SPQR as implementor.
• Recommendation: Needs more testing, and discussion, but generally in favour of moving to wholly TEI-based language. Does not necessitate move to P6 (but major P5 version possibly). (Solving it other way, relaxNG, would necessitate move to P6)
• The Crystal Maze
• LR presented crystals
• LB, SR, & SB think we should investigate whether <specGrp> and <specGrpRef> are sufficient (LB & SR think they will be sufficient, SB is suspicious …) probably work for simple case, but will they do for more complex use-cases.
• Need for “crystal library” how to address and chain together predefined chunks of declaration
• Need for subclassing elements (and bringing in their documentation); bringing in <desc> and <gloss> etc.
• In general in TEI we defer evaluation of pointers until as late as possible, so what order of precedence takes place in evaluating pointers since one may affect the others. (Need better specification of ODD.) (Xinclude being another option since that is how specGrpRef… still needs customisation.)
• When using a crystal you are doing so within its own context/scope… but this is mostly an implementation/specification aspect. How do you decide what to do with conflicting crystal customisations / priority.
• Problem if you take two contradictory crystals. Currently all pointers, rather than grab a copy of it. (If modified would need a different way to refer to that customised version)
• suggestion of @context on specGrpRef to take multiple xpaths?
  • or perhaps only take a @type value
• Recommendation: Good idea, but may already to be done, given a library structure. Need more use cases and attempts at formalising. LR to try existing mechanisms, and see if that solves the crystal problem. Then look at whether @context addition will be useful, if even possible in RelaxNG
• SPQR attempted a notation for this: <schemaSpec xmlns:rng=”http://relaxng.org/ns/structure/1.0″ source=”file:///usr/share/xml/tei/odd/p5subset.xml” ident=”SPQR-crystals”>

<!–

first set up a group/crystal which references <monogr>, and

changes <title>

–>

<specGrp id=”JCmonogr”>

<elementRef key=”monogr”/>

<elementRef key=”title”/>

<elementSpec ident=”title” mode=”change”>

<model>

<pcText/>

</model>

<attList>

<attDef ident=”special” ns=”http://www.example.com/foo” mode=”add”>

<datatype>

<rng:text/>

</datatype>

</attDef>

</attList>

</elementSpec>

</specGrp>

<!– the next group references <analytic> –>

<specGrp id=”SBanalytic” >

<elementRef key=”analytic”/>

</specGrp>

<!– the main biblStruct group references the first two groups,

some more elements, and changes att.global –>

<specGrp id=”SPQRbibl” xmlns=”http://www.tei-c.org/ns/1.0″>

<p>My view of TEI’s biblstruct</p>

<specGrpRef target=”#JCmonogr”/>

<specGrpRef target=”#SBanalytic”/>

<elementRef key=”monogr”/> <!– not an error even though I get it from JCmonogr –>

<elementRef key=”biblStruct”/>

<elementRef key=”publisher”/>

<elementRef key=”author”/>

<classRef key=”att.global”/>

<classSpec ident=”att.global” type=”atts”>

<classes mode=”replace”/>

<attList>

<attDef ident=”n” mode=”delete”/>

<attDef ident=”rend” mode=”delete”/>

<attDef ident=”rendition” mode=”delete”/>

</attList>

</classSpec>

</specGrp>

<!–

Now we can reference the biblStruct group in two ways.

Firstly, same as current specGrpRef macro inclusion,

where the redefinition of <title> and att.global are global

–>

<specGrpRef target=”#SPQRbibl”/>

<!–

Secondly, we pull in the same group,

but this time as a local copy, with a scope of the

element defined by @context –>

<!–

change needed to TEI: add @context to specGrpRef

(defaults to ‘global’)

–>

<specGrpRef target=”#SPQRbibl” context=”listBibl bibl”/>

<!–

Thirdly, a new group references the biblStruct

one, but overrides one of the changes and adds a new

element

–>

<specGrp id=”dougsbibl”>

<specGrpRef target=”#SPQRbibl”/>

<elementRef key=”pubPlace”/>

<elementSpec ident=”title” mode=”change”>

<desc>new description</desc>

<attList>

<attDef ident=”special” mode=”delete”/>

</attList>

</elementSpec>

</specGrp>

<specGrp id=”rp”>

<elementSpec ident=”p” mode=”change”>

<content>

<rng:text/>

</content>

</elementSpec>

<elementSpec ident=”note” mode=”delete”/>

</specGrp>

<!–

It is possible that we might want to

be more precise about the context, using

XPath syntax

–>

<specGrpRef target=”#SPQRbibl” context=”back/listBibl”/>

<specGrpRef target=”#SPQRbibl” context=”text[@type=’special’]”/>

<specGrp id=”rab”>

<elementSpec ident=”ab” mode=”change”>

<content>

<rng:text/>

</content>

</elementSpec>

</specGrp>

<specGrpRef target=”#rp” context=”teiHeader link”/>

<specGrp id=”bg”>

<specGrpRef target=”#rp” context=”p”/>

<specGrpRef target=”#rab”/>

</specGrp>

<specGrpRef target=”#bg” context=”body”/>

<specGrpRef target=”#rp” context=”div[@type=’foo’]”/>

<specGrpRef target=”#rp” context=”model.pLike”/>

<specGrpRef target=”#rp” context=”div.foo fileDesc”/>

</schemaSpec>