Difference between revisions of "New ODD processing"
Jump to navigation
Jump to search
(Created page with "This page is where Syd Bauman, Martin Holmes, and others are keeping notes on their plans for building a new ODD processor. Category:New ODD Processing") |
m |
||
| Line 1: | Line 1: | ||
| − | This page is where Syd Bauman, Martin Holmes, and others are keeping notes on their plans for building a new | + | 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 | ||
| + | * Resides in TEI/TEIC/ repo | ||
| + | * Driven by <tt>ant</tt>, 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. | ||
| + | |||
| + | |||
| + | === plans === | ||
| + | * Do want to re-write generation of p5subset, but we may rely heavily on existing code | ||
| + | * Step 0: nail down the rules for PureODD | ||
[[Category:New ODD Processing]] | [[Category:New ODD Processing]] | ||
Revision as of 18:10, 27 August 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
- Resides in TEI/TEIC/ repo
- 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.
plans
- Do want to re-write generation of p5subset, but we may rely heavily on existing code
- Step 0: nail down the rules for PureODD
