8月22日午间,共创软件联盟发布了详细报告,就微软文档标准的问题做出详细阐述,其中共分六大类二十个主要问题.这是目前国内首份关于微软文档标准OOXML的详细报告发布.
报告中,共创软件联盟公开表示,“微软OOXML技术规范文本长达6000页,任何人甚至一个组织要对其进行详细的研究在短时间内都是不可能的任务”.并指出,报告中所阐述的问题,也说明了共创软件联盟为何反对这一标准.

其中强调，微软OOXML在XML 技术上并不过关，甚至其本身都不符合XML 标准。也包含大量没有详细定义的技术指标和私有技术，这些私有技术只有在微软的Window 平台上实现，而无法在其他开源操作系统之上实现。同时，“OOXML 标准并没有实现其开放微软Doc文档格式的承诺，也就是说并不是所有人都能够通过OOXML实现一个开放的文档格式，这种开放性只掌握在微软手中”。

此前，共创软件联盟曾公开反对微软文档标准，并建立网站征集签名反对。微软目前正在快速推动这一标准成为国际标准，这一进程将在9月2日正式揭晓。

8月21日，国内另一大软件厂商金山也公开表态反对微软文档标准，并公开呼吁国内软件企业不要上微软的当。此前包括红旗中文2000、上海中标软等多家软件厂商在内的软件公司都表示了反对意见。部分专家也呼吁中国政府对这一标准说“不”。

以下为报告全文：

关于微软OOXML技术问题的初步总结

鉴于微软OOXML（在ISO提案的编号为DIS29500）的技术规范文本长达6000页，任何人甚至一个组织要对其进行详细的研究在短时间内都是不可能的任务。然而在开源社区和互联网世界里，许多技术性的研究都可以互相共享。

近期，共创软件联盟专家及办公软件工作组 在罗列、归纳、整理开源社区及互联网上各种版本的有关OOXML的技术问题研究报告基础上，对一些重要的技术问题进行了严谨的文献验证，初步把OOXML 的技术问题归结为六个大类，并列出了其中相关的二十个主要问题。这些问题的归纳、总结基本明确了为什么共创软件联盟要公开表明反对OOXML成为国际标准 的理由。

OOXML六大类技术问题如下：

一、OOXML 标准并没有实现其开放微软Doc文档格式的承诺，也就是说并不是所有人都能够通过OOXML实现一个开放的文档格式，这种开放性只掌握在微软手中。业界希望微软能够将建立起.Doc文档与OOXML之间的映射关系，以实现文档的真正开放；

二、OOXML包含大量没有详细定义的技术指标和私有技术，这些私有技术只有在微软的Window 平台上实现，而无法在其他开源操作系统之上实现；

三、OOXML并没有引用现有的国际标准实现现有的通用功能，却使用其自身定义的私有标准来实现。这不符合定义标准的惯例。相反OOXML 标准中却包含了大量的微软私有技术，以期通过OOXML 成为国际标准。例如，VML等等。

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

五、OOXML仅仅反映西方主流文化，没有考虑其他国家的文化需求。

六、目前OOXML只有唯一的实现，就是微软的Office2007，而没有其他的第二种实现，这也不符合标准的“一个标准，多个实现”的原则。

详细案例列举如下：

一、OOXML标准并没有实现其开放微软 .Doc文档格式的承诺，也就是说并不是所有人都能够通过OOXML实现一个开放的文档格式，而这种开放性只掌握在微软手中。业界希望微软能够将建立起. Doc文档与OOXML之间的映射关系，以实现文档的真正开放，实现与其他标准的互操作；

（1） 没有在OOXML和微软Office97-2003二进制格式之间建立映射关系，导致无法实现互操作，OOXML 标准无法支持符合标准的软件应用实现Microsoft Office97–2003文档与该标准格式的转换。

在Microsoft Office97–2003格式与DIS29500定义的格式之间没有定义映射关系。由于缺乏这种映射，向定义格式的转换将是不稳定的。而且，缺乏这种映 射关系也导致了采用该格式的软件应用与现存Microsoft Office 97–2003格式的文档之间无法实现互操作。这也说明不可能有任何实现OOXML的应用可以反向兼容现存的二进制历史文档，这是与ＯＯＸＭＬ声称其应成 为国际标准的理由相违背的。

（2） 不能与现有国际标准ODF互操作。很多技术细节表明，OOXML与ODF无法实现完全的互操作。同样的，与我国国家标准UOF也不能实现完全的互操作。

二、OOXML 包含大量没有详细定义的技术指标和私有技术，并且私有技术只有在微软的Window平台上实现，而无法在其他开源操作系统之上实现；

（3） 定义了多个非标准加密算法。OOXML采用了早期版本Office软件中采用的哈希算法，而没有采用ISO/IEC 10118-3:2004 加密算法，这也影响了互操作性。甚至连微软本身也不推荐采用这些算法。

（4） 仅仅列举，而没有定义很多“符合性设置”。OOXML中的WordProcessingML列出了大量的“符合性设置”，以便于存储原有应用功能的相关信 息。这些设置的名称包括“useWord97LineBreakRules”，“footnoteLayoutLikeWW8”， “autoSpaceLikeWord95”以及“useWord2002TableStyleRules”等。然而，OOXML规范仅仅列出了这些设置 的名称，但是并没有定义。因此，“完全兼容现有的当前微软格式”（OOXML 标准的承诺）仅仅对于微软是适用的。

（5） 仅仅列举，而没有定义多个“样式”。OOXML中的WordProcessingML 列举了大量的“样式”，例如“chicago”，“ideographDigital”， “ideographLegalTraditiona”，koreanDigital2”以及“koreanLegal”。这些只是标签，而没有精确定 义。OOXML标准的实施者只是知道有一个称为“Korean Legal Numbering”的样式，但是并不知道其意义，以及如何在应用中采用。如果没有明确的定义，没有人能够实现这种样式，也就无法实现OOXML承诺的互 操作。

（6） 没有详细的帐户描述以及数字身份信息来保证电子表单处理的安全性。OOXML中的SpreadsheetML部分描述了一个 “securityDescriptor”属性，是一个重要的与安全相关的属性，告知应用软件软件哪一个用户可以被允许不用密码就可以存取一个区域。 OOXML标准的实施者需要了解用户信息如何在文档中描述。但是OOXML并没有提供这些详细的信息。而且，标准中也没有统一的数字身份的概念。这一功能缺乏足够的定义来实现互操作。

（7） DrawingML 中的“Slide Synchronization Properties”特征没有提供足够的关于通讯协议和数据定义的描述。

DrawingML 中的“Slide Synchronization Properties”实现了幻灯片与中央存储服务器的内容同步，这是Microsoft PowerPoint和SharePoint功能。然而，OOXML 中特征的描述缺乏足够的细节，也没有通讯协议和数据模型的定义，导致这一功能无法独立实现，而唯一的实现就是Sharepoint。

三、OOXML并没有引用现有的国际标准实现现有的通用功能，却使用其自身定义的私有标准来实现。这不符合定义标准的惯例。相反OOXML标准中却包含了大量的微软私有技术，以期通过OOXML成为国际标准。例如，VML等等。

（8） 采用两个非标准的方法描述矢量图形。OOXML没有采用现存的SVG标准来描述矢量图形，而是采用两个非标准的标记语言来 实现。其中一个是VML，此语言于1998年被W3C否决成为标准，另一个是微软独立开发的技术。这就要求OOXML的实施者为同一种功能采用两种不同的 标记语言（都是非标准），而且对于用户没有任何价值，只有微软会从中获益，因为其早期的产品中已经支持了VML。而且，矢量图形也不能很好地通过转换器实 现格式转换。因此，矢量图形的冗余标准将会导致无法实现格式转换。

（9） 由于历史原因不采用使用广泛的“The Gregorian Calendar”。如果询问“1900 年2 月1日是周几”？OOXML将给出错误的答案。这也导致了OOXML电子表单无法实现与SQL 数据库的互操作，因为SQL数据库明确支持Gregoriancalendar。这说明微软自己的产品都没有实现互操作。

（10） 技术建议前后不一致。OOXML建议打印设置应当存储在一个依赖于平台的二进制格式中。例如，在Windows中，存放在“DEVMODE”结构中。如此 实现则导致平台依赖，影响互操作性。但是同时，微软在其XPS规范中却提供了基于ＸＭＬ的PrintTicket元素来存放。可见其技术建议前后不一致。

（11） 基于DRM 的保护无法实现。Office2007中提供了基于DRM的保护，作为OOXML的扩展，但是并没有文档化。由于DRM没有文档，其他厂商无法自由实现这些功能。Office2007中加密的文档不能由其他符合标准的软件阅读。

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

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

（14） WordProcessingML中的“optimizeForBrowser”元素仅仅针对IE浏览器。

WordProcessingML中的“optimizeForBrowser”元素仅仅针对Internet Explorer，而没有针对其他浏览器。

（15） WordProcessingML为数值列表定义一些数字样式，仅仅是标签，没有详细的定义。

这些样式都是从微软的产品中继承的，而且是封闭的，用户无法扩展。然而，样式列表也是不完整 的，缺乏对于Armenian, Tamil, Greek alphabetic, Ethiopic和Khmer数值列表的支持。而微软没有采用的W3C's XSL:FO以及ODF 中采用的，均允许采用开放的数值样式，每个都是自定义的。

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

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

（17） 采用“bitmasks” 编码方式在整型数值中存储布尔值，使得XML无法有效处理。

在很多情况下，OOXML采用”bitmasks”在一个整型数值中编码多个布尔值。在20 年前，由于存储器的限制，C语言采用了这种方法，但是在XML 的处理中却是非常不合适的。它使得XSLT无法很好地工作，因为这些工具缺乏位一级的操作在位一级处理数据。

（18） 仅仅限制语法而不是语义，导致无法实现互操作。OOXML 仅仅限制语法。从实际角度来看，由于OOXML中的语义尚未定义，将导致无法正确实现互操作。

五、OOXML仅仅反映西方主流文化，没有考虑其他国家的文化需求。

（19） 没有考虑到不同的文化需求，而只是反映微软所代表的发达国家的需求。例如OOXML中的NETWORKDAYS()函数的返回周末的值。有的国家这个值是 周六或周日，有的则是周四/周五或者周五/周六。OOXML 并没有提供给不同文化以不同的选择和定义。相反在ODF和UOF 中，用户可以通过设置参数获得其所需值。

（20） 图形边框也是以西方为中心图形边框显示的图形也都是以西方为中心的。OOXML 的实现者不能扩展这些图形，否则将不符合OOXML 定义的要求。

六、目前OOXML只有唯一的实现，就是微软的Office2007，而没有其他的第二种实现，这也不符合标准的“一个标准，多个实现”的原则。

从以上总结中，共创软件联盟办公软件工作组再强调两点：

1、微软OOXML并没有和DOC建立一一映射关系，相互间也存在互相兼容的问题。在有些领域里，微软Office2007对DOC格式的兼容性甚至不如相应的国产办公套件。

2、微软OOXML不可能在Linux完全实现。

共创软件联盟办公软件工作组

2007-8-22

（责任编辑：A6）