Plans

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

• Create Schematron to police our XSLT.
• Create an Oxygen project to associate the Schematron with XSLT files.
• Create a testing infrastructure (location(s) for XSpec files; Ant driver for XSpec; location(s) for other tests if we have any).
• Nail down the rules for PureODD tagdocs elements so that we know what we need to process.
• Start with the processing of end-of-chain ODD content (what was processed_odd) into RELAXNG.
• Move on to ODD chaining.
• 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.
• Work on the documentation rendering component.

Notes

• We might went to develop a mechanism for a specification element (say, <elementSpec>) in the derived ODD to retain the information about which base ODD it came from. (We don’t want this to be on @source, though, because the derived specifications need not be derived again). This leads to a bit of a conundrum, does the output of processing a 2nd customization ODD that uses the 1st derived ODD as a base use the original base or the 1st derived ODD as its provenance? Probably both, eh?
• Reminder to ourselves: There are going to be times when we see that ODD could use some improvements. If we were to convince Council to change ODD now, however, then someone (probably us) would need to change the current Stylesheets, too. One of the main reasons we want atop is to have a processor that is more maintainable. So in general our goal should be to represent what ODD does now, with an eye towards upgrading ODD (and atop to go with it) later, after the world has adopted atop.