^{对微软标准我所坚持的观点}

    目前，因为临近决定OOXML命运的新一轮投票，有关OOXML的新闻和舆论展开了新一轮的爆发，有很多人，通过各种渠道征求我对此的看法。我在此前也曾说过，微软无论是对外公布DOC二进制格式，还是宣布支持中国国家标准UOF,都是值得肯定的进步，但OOXML自身存在的问题和我们反对OOXML成为国际标准的理由仍然存在，我所坚持的对OOXML的原则态度保持不变。

    自 2007年 9月 2日 ISO组织对 DIS29500投票结束后，微软对各国提出的 3522个问题进行了答复。经过前期对 OOXML的研究以及近期对微软的回复评估以后，我们认为 OOXML并不是一个成熟的开放标准，还有待于认真研究和改进，并不适宜走 ISO的快速通道。具体有以下几个基本看法供参考：

一、OOXML不是一个成熟的、全面开放的标准

1、OOXML文本展现形式说明该标准缺乏标准制定的严谨性

    该标准是微软为了应对开放标准趋势和挑战，匆忙推出的，标准文本也极为冗长，共有 6000 多页，各国针对OOXML共提出了3522个问题，经微软归纳整理后也达到了1000 多条。其中有许多问题是文字性的错误，说明该标准制定过程缺少严谨性。目前，按照微软的回复，标准的文本将会做结构性的大调整。一边向国际标准快步“迈进”，一边是进行结构性大调整，这在国际标准史上也不曾得见。这些都充分说明OOXML的出台过于仓促，缺乏制定标准应有的严肃性，它的“晋级”势必将影响国际标准本身的严肃性。

2、在许多重要环节只顾及微软产品的兼容性而拒绝采用国际标准

    虽然OOXML明确表示要尽可能地采用国际标准，但是在一些关键性的环节中仍坚持使用自己的东西，使该标准刻上了明显的私家协议性质的烙印。最典型的就是在对于办公文档很关键的图形描述中采用DrawingML，而不采用W3C的SVG。虽然在一定程度上舍弃了VML，但是仍没有真正采纳国际联盟制定的标准。在 Ecma 的解释中，反而用“DIS 29500 兼容SVG”混淆视听。

    此外 ，OOXML 还定义了多个非标准加密算法，与真正意义上的开放标准背道而驰。如OOXML采用了早期版本Office软件中采用的哈希算法，而没有采用 ISO/IEC 10118-3:2004 加密算法，这也影响了互操作性。而这些算法，甚至连微软本身也不推荐采用。

    OOXML与显示数学公式的行业标准语言（MathML）不兼容。该标准语言大多被研究机构和大多数最著名的出版机构所用，如科学，自然，等等。在 OOXML 说明书中没有涉及与MathML的互用性，这将不利于标准的广泛施行。微软在最近的答复中虽然提供了可以兼容 MathMl 的方式，但还不完整。

    这些都给我们一个强烈的印象：虽然微软一直宣称OOXML是个开放的标准，但标准的内容本身和微软针对各种意见的答复都反映出，微软OOMXL并不是一个真正开放的标准。

     3、OOXML在 XML技术上并不过关，甚至其语言本身都不符合XML标准

OOXML并不完全符合XML语言的要求。OOXML定义了新的字符串类型“Basic String”，作为“二进制基本字符串类型”。这个新的字符串类型的一个特点是允许非XML字符（控制字符）可以特别编码。然而， XML文档中的非XML字符基于XML的处理工具无法处理此XML文件。 W3C'sInternationalization Activity确认，这种控制代码的表达应当由合适的标记语言替换。由于XML提供了编码结构化数据的标准化方法，采用控制字符，而不是标记语言将丧失了采用XML语言的优势。在HTML和XHTML中采用控制代码是不合适的，因为标记语言适宜用来表达文本，而不是数据。

二、OOXML缺少可供第三方实现的实施指南

我们的格式兼容实践表明，办公软件文档格式仅能够确保文档的格式和内容被正确记载，但无法做到精确的版式兼容。如果版面算法不一致，跑版现象是难以克服的。Ecma并没有公布OOXML相应的实现指南，特别是版面算法，因此，OOXML的初衷，即通过OOXML让众多的实现人员能够忠实的再现以前的所有办公文档将成为空话。

ODF有开源的OpenOffice作为参考实现使人们得以分析其版面算法，但 Microsoft Office则不能。由于缺少真正的实施指南，微软 Office2007就成为了OOXML的唯一实施标准。微软制定了一个“开放”的标准，但所提供的实施标准就是 Office2007；由于Office2007的封闭性，反过来决定了微软是OOXML的唯一实现者。

而另一个更为严峻的问题在于，现在的OOXML按照各方的要求修改后，微软Office2007是否也能随之修改，使其能继续符合OOXML标准。由于缺少符合性测试案例，我们甚至无法确认Office2007是否符合该标准。换言之，完全可能出现的情况是：在OOXML成为国际标准后，市场上根本就不存在完全符合该标准的产品。

三、OOXML依然不能在 Linux上实现

OOXML存在明显的平台依赖性，其所定义的有些行为在Windows上可实现，但在 Mac、Linux、Unix 或其他平台上就不能实现，更何况其提供的某些加密算法还依赖于处理芯片。如：

1、剪贴板格式是私有的 Windows 格式

OOXML定义了ST_CF类型用于记录剪贴板格式，以便于存储图形对象。其类型的值如 EMF、WMF等等都是私有的 Windows格式，其他的操作系统无法使用。例如，在Linux中，经常采用开放标准格式PNG，但是如果厂商在此类型中加入“PNG”，则此文档将是非法的，文档及其应用也将不符合OOXML规范。

2、电子表格中的密码哈希算法是依赖于机器的

电子表格中的密码哈希算法定义由5页纸的C语言代码来定义，似乎是从Excel中直接提取的。然而，代码中的位控制又是依赖于机器的，根据处理器的不同会给出不同的结果。在一个机器上建立的文档可能在另一个机器上不可阅读。关于此功能，OOXML没有提供一个便捷的定义。

OOXML的平台依赖性对国产操作系统和国产芯片都将是致命的打击。在确保微软OOXML能成为与平台无关的真正开放的标准前，我们必须对此标准持反对态度。

四、微软需要承担 Doc 与 OOXML 全面转换的责任

过去国产软件被迫单项兼容微软 DOC 源于 DOC 的封闭性。微软在抛弃封闭格式，迈向开放标准的过程中，应进一步拿出诚意和实际行动，主动解决封闭格式造成的历史遗留问题，并确保真正走向开放，不再利用自身格式转换取得独家竞争优势。换言之，由于DOC和OOXML均是微软的标准，目前，世界上只有微软拥有处理自己这两种格式的互操作能力，因此微软应该确保所有用户获得处理这两个格式的能力。微软应该公开自己已完成的DOC和OOXML转换模块；而不应停留在支持第三方另起炉灶的阶段，还会有故意拖延用户和竞争对手时间之嫌。

结语：

    之前OOXML自身存在的问题和我们反对OOXML成为国际标准的理由仍然存在，并未随着微软的回复而得到根本性的解决。我们认为此前中国政府在投票过程中的建议是非常理性、合理的：DIS 29500（即OOXML）不适合快速通道，应转变快速通道为常规程序，或延长评审期限。