ZedDist Text Grammars
This page is under construction. See also ZedDist_Document_Text
This is a landing page page for ZedDist design goals relating to Text Media;
In terms of Text Media, there are different options and permutations relating to the notion of distribution profiles:
- some profiles may not include the Text content type at all
- but others will, and among these
- there may be a per-profile degree of freedom in terms of which grammars to use
- there may be a rule that a particular (root, at least) grammar must be used (think: with a compound document (CDR or CDI) extension point).
In either case, spec or profile designers alike will have to deal with the requirements stemming from set targets. Solution options are outlined here.
Option 1: build on the XHTML Namespace and Core Grammar
This solution is based on the notion of reusing the XHTML namespace and (a strictened-up subset of its) grammar to maximize mainstream and, in particular, browser compatibility. There are two major approaches to implement this:
Option 1a: Use XHTML 1.1 Modularization
Based on XHTML 1.1 Modularization, a core grammar is built by using a subset of the available XHTML11 modules, and adding a number of our own modules, as needed.
- Good styling support
- Is inherently extensible; we can add support for the flexible semantics target for example via an injected z3986-role attribute
- Is inherently extensible; we can add support for the Dynamic Extensibility target via CDI
- Also supports CDR extensibility via object, with a given fallback mechanism
- May result in compatibility/consistency problems with HTML5 (and earlier) DOMs (when served as text/html). (This should however be avoidable with proper Appendix-C-style masquerading guidelines)
- The Compound-document-by-namespace approach is incompatible with HTML5.
- The future of XHTML 1.1 is uncertain - it may
- be revived and taken through future revisions (likelihood: very low)
- be left as-is (likelihood: medium)
- be formally deprecated by the W3C (likelihood: unknown)
Option 1b: Use a subset of XHTML 5
In this approach, a subset of XHTML5 is used, basically removing all the webapp stuff that doesnt pertain to our document-centric use-case, and imposing one or several subsetting passes that stricten up the structural requirements.
- Good styling support (in the short term at least in Webkit, Mozilla and Opera)
- Fully predictable HTML5 DOM, if the polyglot guidelines are consistently enforced the document can even be served as text/html, which extends the good styling support even to current IE
- Supports CDR extensibility via object (@@@ related to nested browsing context)
- Contains a number of elements (in the default namespace) that are useful to us, and dont exist in XHTML11 core (section,article,aside,@@@)
- XHTML5 officially supports namespace-based extensibility, but behaviors and principles are not described as in XHTML1.1 and HTML5 compat breaks if using any other namespace than XHTML, SVG or MathML. (Note: this is still under discussion in W3C - this statement based on first WHATWG LC. See also DecentrailzedExtensibilityandHTML_v9.pdf)
- Unclear at this point how to implement the flexible semantics target (depends on: Microdata vs RDF/a); note that HTML5 does allow @role for use with the ARIA vocab (@@@ extensibility here seems not to be intended)
- Uncertain when HTML5 will be a final W3C rec.
Additional Notes on the XHTML approach
There is a possibility here to harmonize with EPUB. We do however not know where EPUB will go in their next revision (although it is likely to be one of the options above).
Option 2: build on non-XHTML grammars, using XBL2, CSS3 etc to achive reasonable rendering