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