Authoring and Interchange Format Strawman 1
From zedwiki
This document describes a first barebones strawman for the DAISY Authoring and Interchange Format (DAIF). It is intended to serve as a starter for discussions during day 2 and 3 at the 200809 GooglePlex meeting.
Note that what is described here has absolutely nothing to do with the text component of a DAISY DTB SMIL presentation; it discusses only the authoring and interchange XML format.
It is expected that more strawmen (strawmans?) will appear that propose mildly and/or radically different approaches.
last edit mgylling 20080914
Contents |
The fundamental problems, condensed
- Semantic Scope and Input Types
- The current DTBook grammar is focused on capturing print book semantics, and thus cannot faithfully represent other input types (think: magazines, newspapers, bank statements, leaflets, etc). When DAISY and DTBook was created, support for the republishing of books was the sole target. As DAISY has expanded over the last ten years, this scope has become too tight.
- Single Source Master and Output Formats
- An increasing amount of organisations in the DAISY community and beyond are looking for an XML grammar that they can use as a single source for various accessible output formats. DAISY DTBs, Braille, Large Print, e-Text are examples of often-mentioned output formats in this context. Whereas some organisations have begun to use DTBook in this manner and succeeded farely well, others have had issues in setting up an parallell publishing infrastructure using DTBook as a fundament. In particular, the automation of print Braille creation has repeatedy been mentioned as a process that cannot easily set up given the current DTBook grammar (see "poor" in 1.3 below).
- Simplicity vs Expressive Power
- The current DTBook grammar is an entire document model that is defined in monolithic form. Some users/adopters think that this monolith is too complex (and consequently too expensive to use); others think that it is too poor (and consequently insufficuent for using as a bridge between a given input source and a desired output type).
- Interchange
- Today, organisations within the DAISY community are exchanging readymade products (DTBs, Braille volumes as examples). Transporting finalized products between locales and and legislations is a suboptimal practice for many reasons.
What do we need to address these problems?
We need a document model that has capabilities for adaption.
- Input Flexibility
- A grammar that is sufficiently flexible, so that it can be adapted to faithfully capture various input types.
- Dynamics re Simplicity and Complexity
- A grammar that is sufficiently dynamic, so that it be in an expansive state (where it would meet the needs associated with complex input and output types) and also in a basic state (where it would meet the needs of those that require the economy of simplicity).
- Output specificity
- The ability to decorate or associate properties to the instance that pertain to specific output types. An often-mentioned example is the use of XSL-FO to describe print braille page layout. A document could be completely neutral in this respect (no output-specific decorations added) and still perfectly conformant. A document should be able to simultaneously carry decorations pertaining to 0-n target output formats.
Fundamental Requirements of a Next Generation DTBook grammar
Neutral Base
The grammar would need a base that is sufficiently neutral (semantically and structurally) so that that it can serve as the fundament for particular input and output natures, without any semantic and/or structural skewing/distortion (think: a root element named "book" is not a good idea).
Composition through modularization+profiles
It would likely use a profiling mechanism: profile composition based on modules.
- The Zed spec itself would provide a set of modules, in their turn composed into a set of "common" profiles that would satisfy the fundamental needs of the community. We can choose whether we want to include only input-related profiles, output-related profiles, or both.
- The spec would define a set of rules for composition, so that agencies with needs beyond those of the shipped profiles can compose their own whilst remaining within the boundaries of compliance.
- The DAISY Zed homepage could carry a "registry" of profiles known to be compliant, although not explicitly mentioned in the spec prose. (Through this, we incidentally also achieve a situation where we do not need to produce modules and profiles for all relevant input and output types in the spec itself.)
Semantic mapping
Because of the extensibility mechanism, it would need a mechanism to describe/map semantics of "unknown" constructs. A DAIF instance will pass through several processing stages (possibly within several organisations) during its lifetime; we need to adopt a "must-process" rule as opposed to the "must-ignore" rule used for example in HTTP. This is the rationale for making semantic maps first-class citizens in this context.
Strawman 1
The document type
- Use a strict subset of XHTML 2.0 as the neutral base (XHTML2 is natively modularized).
- To replicate DTBook current, create a set of "Print Book Semantics" modules in a namespace separate from the host namespace, and import those onto the XHTML 2.0 base. Result is expressed as a profile.
- For other input types than the print book, repeat #2 above but with other types identified in the module. These are also expressed as profiles, created by the document producers and/or republishers as needed (not part of specification itself).
- To add support for output-specificity, repeat #2 above to include types that provide the output formatting data. Example: including SSML to control pronunciation in TTS processing. These are also expressed as profiles.
- Use the xhtml:role module for semantic mapping. This module is native to XHTML2. xhtml:role would be required for all elements beyond those in the neutral base (i.e., all elements that are not in the xhtml2 namespace). Consequence: all imported modules must in their turn import the xhtml:role module; this is one of the composition rules.
Composition declaration and instance conformance validation
In the simple case, all modules use the same Schema language, and composition through extensions and overrides can be achieved using the Schema language built-in features (the "driver" schema composition pattern).
However, we need to support the case of a profile being composed by modules using different schema languages. For this reasons, we adopt NVDL as the ultimate way to declare a profile composition. NVDL actually makes the 4.2.1 approach redundant (NVDL can be used all the time if we so want). NVDL is also by itself a validation language.
We define a universal method for an instance to locally declare which profile it adhers to (typically: an indirect symbol within a "profile" attribute on the root element). The potential use of RDDL also springs to mind here, but whereas RDDL is intended to be a per-namespace resource discovery language, what we really need is a per-compound-profile resource discovery language.
Strawman 1 issues and questions
- What happens to my beloved DTBook grammar?
- DTBook inherits a lot of constructs from HTML/XHTML1 in the first place (both good and bad ones). The above approach continues in that vein, but uses a namespace-compound approach, which is politically and technically more appropriate from a general XML design perspective. Namespaces and compound documents did not really exist when DTBook was originally created.
- XHTML is very loose! Will this not cause problems?
- XHTML 2.0 is completely revamped and much cleaner grammar as compared to XHTML 1.x. For example, it uses the level wrappers just like DTBook. Nevertheless, using XHTML 2.0 as the base would require that we can define subsets of it that explicitly disallows unwanted content models. This in its turn depends largely on the granularity of the XHTML 2.0 modules themselves. (There are workarounds, such as providing an addon set of Schematron assertions for our context, but this should ideally be avoided at this fundamental level).
- XHTML 2.0 is still in working draft stage! Will this not cause problems?
- This is both good and bad news. Should we decide to adopt XHTML2, we still have the change to propose changes to it. At the same time, we are dependant on XHTML 2.0 becoming a final rec before NISO process finalization.
- Do we really need a static base at all? Isnt the concept of a host grammar moot? Given the RDF mapping, we can theoretically use any grammar anywhere as long as there is an RDF Taxonomy that defines included natures.
- Theoretically, this could be so. But it is a rather extreme approach, and one can question whether it has any real-world benefits. Intuitively, a certain amount of fundamental predictability seems preferable.
