New ODD processing - Revision history

Mholmes: /* ATOP: Another TEI ODD Processor */

2022-04-06T15:24:08Z

‎ATOP: Another TEI ODD Processor

2022-04-04T16:24:40Z

‎plans

2022-03-28T15:26:26Z

‎plans

2022-03-21T16:58:18Z

‎goals

2022-02-28T22:12:33Z

‎plans

2022-02-28T22:07:11Z

‎goals

2022-02-28T17:16:06Z

‎goals

2022-02-28T17:15:46Z

‎goals

2022-02-28T17:14:45Z

‎goals

2022-02-26T17:43:25Z

‎goals

← Older revision		Revision as of 15:24, 6 April 2022
Line 2:		Line 2:

	==ATOP: Another TEI ODD Processor==		==ATOP: Another TEI ODD Processor==
		+
		+	NOTE: This content has been migrated to the ATOP repo wiki:
		+
		+	https://github.com/TEIC/atop/wiki

	=== goals ===		=== goals ===

@@ Line 43: / Line 43: @@
 # 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.
 === unresolved questions ===

← Older revision		Revision as of 15:26, 28 March 2022
Line 43:		Line 43:
	# 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.		# 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.		# Work on the documentation rendering component.
		+
		+	=== unresolved questions ===
		+
		+	The issue of how to handle multiple languages when ODD chaining is problematic:
		+
		+	1. Imagine:
		+
		+	p5subset.xml has all the languages (as it does);
		+	customization1.odd specifies @docLang="en"
		+	customization2.odd, which points to customization1.odd, specifies @docLang="it"
		+	What language should the output schema use?
		+
		+	2. Imagine:
		+
		+	customization1.odd modifies an element, replacing the English gloss with something different.
		+	customization2.off specifies @docLang="es"
		+	Where should the gloss be taken from in the output of the chain?
		+
		+	3. Should it be part of the system that you can specify a series of languages in order of preference, from which text will be taken if something is not available in the main docLang?

@@ Line 12: / Line 12: @@
 * 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

@@ Line 33: / Line 33: @@
 === plans ===
 Not ''necessarily'' in this order, but it is a reasonable one.
 # 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.
+# Work on the documentation rendering component.
 # Re-write generation of p5subset, likely relying heavily on existing code
 [[Category:New ODD Processing]]

← Older revision		Revision as of 22:07, 28 February 2022
Line 1:		Line 1:
	This page is where Syd Bauman, Martin Holmes, and others are keeping notes on their plans for building a new PureODD processor.		This page is where Syd Bauman, Martin Holmes, and others are keeping notes on their plans for building a new PureODD processor.
		+
		+	==ATOP: Another TEI ODD Processor==

	=== goals ===		=== goals ===

@@ Line 27: / Line 27: @@
 * We are still debating whether to support PureODD only, or RELAX NG inside &lt;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 schemaSpec) should be .odd, and non-TEI XML should be .xml unless there is another more suitable extension for their type.
+* 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 <schemaSpec>) should be .odd, and non-TEI XML should be .xml unless there is another more suitable extension for their type.
 === plans ===

@@ Line 6: / Line 6: @@
 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)
+* 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 <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)