共创联盟报告指微软文档标准有20大问题

来源: LUPA开源社区

　　二、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中加密的文档不能由其他符合标准的软件阅读。
声明：LUPA开源社区刊登此文只为传递信息，并不表示赞同或者反对。