Goals

This is the rough list of goals we developed initially on the TEI wiki, in no particular order:

• Written in XSLT 3, only
• Eventually we hope it will reside in TEI/TEIC/ repo, but development will be in a separate repo under TEIC; some Council members believe the ODD processing should be kept distinct from the P5 source.
• Driven by ant, with the hope, but not requirement, that it will run in Windows (requirement that it runs in oXygen)
• Probably best to build an oXygen plug-in as we go (or at least as soon as there is a transform that works)
• No support for DTDs
• Should we attempt to flag up scenarios which will generate ambiguity that will not convert to XML Schema? Perhaps if we have ODD-to-XSD, we should follow it with Xerces validation of the resulting schema to catch ambiguity issues.
• Support for Schematron (ISO or the new community Schematron, but not both) via putting rules into RELAX NG, then extracting to separate .sch file from there
  • Note: per some investigation by RVDB, this means not expressing a query binding, and thus we may want to reconsider.
• Plan to use HTML5, rather than a bastardized TEI_Lite, as intermediate stage
• Well documented (using xd: elements and comments — at least partially enforced by Schematron), using consistent naming conventions, typed variables, etc.
• naming conventions: camelCase for variables, hyphenation-for-functions().
• For vars/params: use a prefix of v for variables and p for params, so that it's easy to see whether a symbol is supplied or constructed in context.
• Require @as everywhere.
• For vars/params: consider devising a sort of Hungarian notation but based on suffixes, that would show the type of a symbol. This would need to distinguish all datatypes and include a sequence component, without being too unwieldy.
• Probably a good idea to have a single “coding conventions” document that discusses these issues, and perhaps some Schematron to enforce them.
• SB thinks we should lean away from iterations and “loops”, preferring apply-templates; MH less strong on this point
• MH prefers functions over named templates; SB less strong on this point
• We agree we would prefer to rely on XSLT 3 maps as opposed to XSLT 1 keys, re-visiting this decision if maps turn out to be problematic (i.e., too slow)
• In order to make running XSpec easier, functions and named templates should be in separate library files.
• We should consider using XSLT modules rather than old-style includes.
• We want to support chained ODDs right from the start
• Generate a test suite (including of chaining) as we go
• We are still debating whether to support PureODD only, or RELAX NG inside <content> as well
• We are considering an approach where processing of a customization ODD (whether initial or chained) is to generate an XSLT program from it that gets run against P5(subset) or its precursor ODD. This would make debugging easier, but presumably would be a bit slower than an in-memory multistage transformation.
• Filenames should use only lower-case ascii and underscores, only use hyphens in hyphenated words, only use the dot for an extension, and only have one extension. XSLT files should have the extension .xslt, non-ODD TEI files (such as test files) should be .tei, ODD files (i.e. TEI files containing a ) should be .odd, and non-TEI XML should be .xml unless there is another more suitable extension for their type.
• Use named templates where elements are being constructed; use functions where more primitive datatypes are the output.