Ross Gardler wrote:
the move to a
RG> subset of XHTML2 is only to enable us to leverage emerging XHTML2 RG> editors
If that is so, would it not make more sense to only support XHTML2 as an input format and stick with documentv-xx for our interal format.
Especially now that xhtml-2 support could be easily offered as a plugin?
Document v2.0 is not the same as the XHTML2 subset we want to support. Plus, we don't know how XHTML2 may change in the future, by adopting XHTML2 as an internal format we remove the need to have XDoc track any changes in XHTML2.
Since XDoc brings no additional value, why keep the overhead?
Perhaps even more importantly, I "forgot" another key reason to using XHTML as the internal format:
Many source formats already provide a set of XSL sheets for transforming into XHTML. If we use that as our internal format we simplify our transformation pipeline. Consider the docbook scenario in this original thread:
Currently, to support the full Docbook format we would have to do:
docbook -> XHTML -> XDoc -> Output format
However, if we adopt XHTML as our internal format this becomes:
docbook -> XHTML -> Output format
This would also be true if we chose to support XHTML as an input format:
XHTML2 -> XDoc ->Output Format
instead of:
XHTML2 -> Output format
So the transformation is more efficient and we need only maintain one set of stylesheets and no schema definitions. Again, if XDoc is bringing now benefit over XHTML why increase out maintenance requirements in order to continue its support?
Finally, users like things to be standards compliant - we can remove a proprietary schema and replace it with a open standard, got to be good.
Ross
