由于某些 Microsoft Office 文档使用以向量语言 VML 绘制的图形，OOXML 说明了如何保存这些图形的方式。这意味着所有实现者都必须阅读这些图形 — 遗憾的是，为他们提供的说明不够详细。您可以在特定项的内部查找字符串形式的 VML。
哪些值是真正被允许的？答案非常明了；“这个属性的可能值由 XML Schema 字符串数据类型定义”。这就是说，它是一个字符串。它可以包含任意的文本，其含义 只能由 VML 库的代码解答。简言之，除非您碰巧使用了 VML 库，否则不可能实现这个要求。
同样，这也是一种特殊行为。在针对交换设计的标准中，需要对图形的格式（可能只有一种）进行完整说明，并且要求使用另一种绘图库的实现者将图形导出 为标准格式。相反，OOXML 仅仅提供了对早期设计的摘要重述（并且有意设计为不能用于其他人），并要求所有人都适应它。
最后一类问题最让众多标准专家感到恼怒。这并不是由于它更加难于实现 — 最困难的实现莫过于根本就不可能实现 — 而是因为本来就不应该存在。这一类特性从某些方面来说完全依赖于 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 格式的概念。在我写它的时候，我自己都觉得有些可笑。但现在看来并非如此。
声明：LUPA开源社区刊登此文只为传递信息，并不表示赞同或者反对。
