Difference between revisions of "New ODD processing"

From TEIWiki
Jump to navigation Jump to search
m (goals)
m (plans)
Line 23: Line 23:
  
 
=== plans ===
 
=== plans ===
* Do want to re-write generation of p5subset, but we may rely heavily on existing code
+
Not ''necessarily'' in this order, but it is a reasonable one.
* Step 0: nail down the rules for PureODD
+
# Nail down the rules for PureODD
 +
# Nail down the subset of TEI that we plan to process (by tangling into RELAX NG and weaving into XHTML 5) by creating a new ODD, or by modifying p5odds.odd.
 +
# Agree upon and document XSLT coding conventions. Keep this in a live document to be updated PRN.
 +
# Re-write generation of p5subset, likely relying heavily on existing code
  
  
 
[[Category:New ODD Processing]]
 
[[Category:New ODD Processing]]

Revision as of 19:54, 30 October 2021

This page is where Syd Bauman, Martin Holmes, and others are keeping notes on their plans for building a new PureODD processor.

goals

We are planning a re-write of current Stylesheets aimed solely at converting ODD to the Guidelines, schemas, and customization ODDs into schemas and customized output. Thoughts, in no particular order:

  • Written in XSLT 3, only
  • Eventually to reside in TEI/TEIC/ repo, but development will be on a fork of said repo (this will allow us to frequently merge in changes from TEIC/TEI/, but to stay out of everyone’s way)
  • 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
  • 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
  • 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.
  • 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
  • In order to make running XSpec easier, functions and named templates should be in separate library files
  • 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
  • Processing of a customization ODD (whether initial or chained) is to generate an XSLT program from it that gets run against P5(subset)

plans

Not necessarily in this order, but it is a reasonable one.

  1. Nail down the rules for PureODD
  2. Nail down the subset of TEI that we plan to process (by tangling into RELAX NG and weaving into XHTML 5) by creating a new ODD, or by modifying p5odds.odd.
  3. Agree upon and document XSLT coding conventions. Keep this in a live document to be updated PRN.
  4. Re-write generation of p5subset, likely relying heavily on existing code