我在标准化领域工作了很长时间（包括近十年来在 ISO C 标准委员会的志愿者工作）。大多数对标准化感兴趣的人对于 Microsoft® 提出的基于 XML 的文档格式 Office Open XML (OOXML) 的标准化过程都有自己的看法。通常，我并不会撰文谈论自己的观点，但就最近 IBM 努力摆脱 OOXML 这一说法，我想表明自己的观点，但首先我要明确声明：我并不是 IBM 的员工，本文所述均是我本人的观点，并且这些想法与 IBM 在这一问题上的立场无关。
从很多方面讲，OOXML 标准确实是一种重要的规范。实际上，不论是否指责 OOXML 标准化过程中的政治因素，围绕它的标准化过程始终充斥着政治纠葛（参见 参考资料）。然而，抛开所有这些政治因素，还存在严重的技术问题，范围涉及 XML 是否是标准的最佳选择以及标准化的目的。所有这些内容都为我提供了很好的切入点，我还将谈论影响 OOXML 成为标准的因素。
对办公文档格式进行标准化的要求非常强烈。从公司到政府等众多组织都制定了诸多规则，要求软件支持面向文档存储的开放标准。人们都不希望受制于单个供应商；标准提供了方法摆脱这种限制。从这些方面考虑，我们来审视一下 Microsoft 提出的 OOXML 标准存在的技术问题。
OOXML 标准源于 ECMA，是一组以 PDF 形式发布的文档，共 6000 页左右。它包含了大量规范，内容涵盖了很多方面。该标准之所以如此庞大，是因为 OOXML 几乎完全复制了 Microsoft Office 应用程序在文件中可能保存的所有数据块。
一直以来，对 OOXML 技术方面的抱怨不绝于耳。所有指责最后都可以归结到最基本的一点：OOXML 并没有指定恰当的通用交换格式，相反，它指定了 Microsoft Office 的整个特性集，内容具体到 bug 兼容性。这为其他实现者制造了难于实现（事实上也不可能实现）的负担，而另一方面，OOXML 标准的内容却是 Microsoft 已经附带的特性。这引起了众多问题。
请不要将此误解为仅仅是对 Microsoft 依仗自身已有特性获得竞争先机的指责；如果 Microsoft 实现的是一个小型的经过良好设计的标准，并且所有人都可以适当实现，那么我们完全可以接受该标准。这些受到指责的问题可归结为三大类：一些特性的实现非常困难，而另一些特性则没有进行充分的说明，还有一部分特性完全属于 Microsoft Office 独有。这三类问题存在一定程度的重叠，但是每一类都代表一种不同类型的障碍。
最后一类问题最让众多标准专家感到恼怒。这并不是由于它更加难于实现 — 最困难的实现莫过于根本就不可能实现 — 而是因为本来就不应该存在。这一类特性从某些方面来说完全依赖于 Microsoft Office。
也许最为人熟知的一个例子就是 OOXML 提供的一个可选设置。这个设置被称为 “useWord97LineBreakRules”，它指明要使用针对 East Asian 文档的 Word '97 中使用的换行规则。与前面的例子非常相似，任何人都不可能做到这一点，因为没有提供有关这些规则的任何说明。事实上，OOXML 标准甚至警告实现者不要实现这个规则：
[指导说明：要如实地重复这一行为，其他应用程序必须仿效这个应用程序的行为，这其中涉及很多可能的行为，因此本 Office Open XML 标准不作一一介绍。如果应用程序希望匹配这一行为，它们必须利用并复制这些应用程序的输出。建议应用程序不要特意复制这种行为，因为其输出可能导致问题，并且维护此规则的目的仅是保证与应用程序现有文档的兼容性。]
这个特性之所以出现在规范中，是因为 OOXML 并不是一个文档交换格式；而是对 Microsoft 以前的二进制格式的精确重复，只不过用尖括号括起来而已。
听取了对 OOXML 的一些抱怨以后，一些 IT 专家认为 XML 并不适合用于标准化。这种论断为时过早。事实上，我认为这种想法完全错误。XML 并不是引起问题的原因；产生问题的原因是决策，即忠实地重复向后兼容性的所有细节以及现有程序的所有特殊行为，而没有指明以在多个应用程序间进行共享和交换为目标的一般性文档的结构和内容。
使用 XML 可以很好地完成这一切。OOXML 最主要的竞争者也是 XML 标准，称为 Open Document Format (ODF)。它绝不是无足轻重的小型标准；ODF 1.1 版是一个共 738 页的文档，开发组认为它还没有完全完成。例如，它还没有定义电子表格中使用的公式语言 — 但是目前正在开发中，将包含到标准的 1.2 版本中。尽管如此，浏览一下 ODF 规范会发现，它并没有尝试描述庞大的遗留应用程序的行为，而是注重描述文档的内容。
XML 的目的是允许您说明希望如何描述文档内容。虽然 ODF 目前还存在缺陷，但至少它能够让人理解。
虽然 XML 是一种定义新文件格式的强大的表示工具，但仍然无法解决可选项目范围狭窄问题。如果您决定生成一个文件格式，在其中使用某种标记说明如何使用大型的未文档化的专用呈现库，那么不论是通过未文档化的二进制字符串指定标记，还是使用尖括号括起的三页文档指定，都变得不那么重要了；您的规范是私有的，并且没有合适的方法呈现它，除非将它包含在 XML 中。
很遗憾，尽管 XML 具有跨越广泛文件格式提供一致的标准化解析的潜能，它在 OOXML 的缺陷方面受到了一些指责。OOXML 共包含 6000 页的说明，而不仅仅关于一个给定的文字处理程序，而是包含很多用途，其中一些只是间接提到，而未做详细说明。甚至可以认为，实现 OOXML 的种种尝试是对底层 XML 标准的健壮性的嘉奖。
OOXML 确实解决了一个问题：对于编码了十年累积行为的晦涩的二进制文件，如何使用编码了相同行为的较为清晰的 XML 文件进行替换。可惜的是，这个问题并不是我们希望解决的问题，即能够提供可用的、可实现的、面向办公文档的交换格式。
如果 Microsoft 希望人们严肃对待作为一项文档标准提议的 OOXML，惟一的方法就是将它摆在桌面上。Microsoft 应该侧重于构建一个更小、更精简的交换 格式，通过完整说明的可实现的方式提供核心功能，而不是尝试开发一个规范，在其中包含未来 Microsoft Office 版本中所有可能的特性，以及某些文档可能会使用的所有标志或特殊行为。不要向只希望复制电子表格数据和公式的用户公开特殊的实现行为，例如 Excel® 计算链。不要公开甚至引用 VML 库、DrawingML 库或其他类似内容的细节；相反，应提供一种全新的、开放的、详细说明的数据描述。
一段时间以前，当我在 XML 之上编写 Standards & Specs 时，我很自然地参考了一种包含 “<bytes>ff ff 00 03 [. . .]</bytes>” 的 XML 格式的概念。在我写它的时候，我自己都觉得有些可笑。但现在看来并非如此。作者: 天灵灵地灵灵 时间: 2008-3-28 00:09
