TEI ODD Format and Multiple Schema language constraints

Excerpted comments from TEI List postings of Sebastian Rahtz and Lou Burnard on the use of TEI 'ODD' literate programming source to generate RELAX NG schemas for TEI, and possibly other constraints for schema languages, all from one specification. See background at ['One Document Does It All'] TEI Format for DTD generation


Date:      Sat, 23 Mar 2002 13:15:30 +0000
From:      Sebastian Rahtz <sebastian.rahtz@OUCS.OX.AC.UK>

[...] The interesting thing, to my mind, about these exercise is not that we have a useable Relax NG Schema for TEI, but that it is derived from the literate programming source of P4. Making a schema from a DTD is relatively easy (James Clark and Sun provide tools), but the fun bit is seeing how we can enhance the source of the TEI with extra constraint hooks. We have an example already in the data type "ISO-date", which expands to simply "CDATA". Plugging in a alternate is as simple as

<define name="ISO-date">
<data type="date"
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"/>
</define>

it might well make sense to put a lot more abstract datatypes like this into P5, so that schema-aware people can attach validation.

more intriguingly, we could also attach abstract constraints to element content models. suppose the model for <title> says "titlePart*" in normal DTD, we could add in a dummy "titleConstraints" rule which a schema could instantiate with a Schematron assertion which said "if there are more than 3 titlePart elements, the second and third must have type attributes"

Date: Mon, 25 Mar 2002 23:49:59 +0000
From: Lou Burnard <lou@ERMINE.OX.AC.UK>

[...] The whole point of the ODD system is that it should express all the constraints you need in one place. That's what the acronym means. Different outputs from that source may be expressed in different schema languaes, as Sebastian has shown; what we have yet to show is how different outputs in the same languiage can express different constraints. So we might use ODD to generate one schema for data capture (very pernicketty about content rules), and another for analysis of the same data. [if projects use a DTD for one phase (say, configuring their editor), a RELaX schema for another (pre-production QA), and end up introducing new constraints in one without reflecting them in the other, then...]

Centralize the constraints. Put them in the ODD. Distribute them to the applications. Multiple schemas.

Prepared by Robin Cover for The XML Cover Pages archive. See Literate Programming.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	TEI ODD Format and Multiple Schema language constraints Excerpted comments from TEI List postings of Sebastian Rahtz and Lou Burnard on the use of TEI 'ODD' literate programming source to generate RELAX NG schemas for TEI, and possibly other constraints for schema languages, all from one specification. See background at ['One Document Does It All'] TEI Format for DTD generation Date: Sat, 23 Mar 2002 13:15:30 +0000 From: Sebastian Rahtz <sebastian.rahtz@OUCS.OX.AC.UK> [...] The interesting thing, to my mind, about these exercise is not that we have a useable Relax NG Schema for TEI, but that it is derived from the literate programming source of P4. Making a schema from a DTD is relatively easy (James Clark and Sun provide tools), but the fun bit is seeing how we can enhance the source of the TEI with extra constraint hooks. We have an example already in the data type "ISO-date", which expands to simply "CDATA". Plugging in a alternate is as simple as <define name="ISO-date"> <data type="date" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"/> </define> it might well make sense to put a lot more abstract datatypes like this into P5, so that schema-aware people can attach validation. more intriguingly, we could also attach abstract constraints to element content models. suppose the model for <title> says "titlePart*" in normal DTD, we could add in a dummy "titleConstraints" rule which a schema could instantiate with a Schematron assertion which said "if there are more than 3 titlePart elements, the second and third must have type attributes" Date: Mon, 25 Mar 2002 23:49:59 +0000 From: Lou Burnard <lou@ERMINE.OX.AC.UK> [...] The whole point of the ODD system is that it should express all the constraints you need in one place. That's what the acronym means. Different outputs from that source may be expressed in different schema languaes, as Sebastian has shown; what we have yet to show is how different outputs in the same languiage can express different constraints. So we might use ODD to generate one schema for data capture (very pernicketty about content rules), and another for analysis of the same data. [if projects use a DTD for one phase (say, configuring their editor), a RELaX schema for another (pre-production QA), and end up introducing new constraints in one without reflecting them in the other, then...] Centralize the constraints. Put them in the ODD. Distribute them to the applications. Multiple schemas. Prepared by Robin Cover for The XML Cover Pages archive. See Literate Programming.