Why I think MCE deserves to be a standalone standard
MURATA Makoto (FAMILY Given)
eb2m-mrt at asahi-net.or.jp
Fri Jul 29 04:12:15 CEST 2011
Dear colleagues,
MCE provides standalone 1) mechanisms for ignoring foreign
elements/attributes, and 2) mechanisms for choosing one of the
options listed within an XML document. It is not only MCE that provides
such mechanisms. For example, SVG 1.1 provides switch and
foreignElement elements, and EPUB 3.0 provides switch elements.
http://www.w3.org/TR/SVG/struct.html#SwitchElement
http://www.w3.org/TR/SVG/extend.html#ForeignObjectElement
http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-content-switch
However, with the exception of MCE, these mechanisms are tightly
integrated as part of the host languages. As a result, it is not
possible to create a thin layer for implementing them. Moreover,
users have to learn similar but different mechanisms. In particular,
EPUB content authors have to learn both SVG switch and EPUB switch.
What a shame!
Meanwhile, MCE is already a standalone specification. It is
technically independent from the rest of OOXML. As demonstrated by
libOPC (http://libopc.codeplex.com/), it is possible to implement MCE
as a thin layer without implementing Parts 1 or 4 of OOXML.
I am not saying that the quality of ISO/IEC 29500-3 is great. I think
that it has a number of problems, as pointed out by some defect
reports. Without thorough rewrite, it is very difficult to understand
MCE from the current text.
We also have to make sure that MCE does meet requirements of other
host languages including SVG and EPUB. We should probably distribute
a working draft to the public, contact committees like SVG and EPUB (
and may be W3C TAG), and solicit feedbacks.
I sincerely hope that MCE becomes a generic, light-weight, and robust
mechanism for controlling document compatibility and extensions,
and many host languages simply adopt MCE.
Cheers,
Makoto
More information about the sc34wg4
mailing list