完美Excel

据csdn袁盟的博客
如果OOXML“遇事不利”(俗称“倒霉”)，过不了3月29日这一关，那么，必然“殃及”（”祸害”）ODF。为什么？

3月24日，作为ODF的执笔人（Editor）Patrick Durusau发表文章，题为“Who loses if OpenXML loses?”（“如果OpenXML失利，谁是受害者？”），尖锐地指出：OOXML（就是他所指的OpenXML）与ODF 两者密切相关，一损俱损。为什么？他认为，如果OOXML没有成为ISO标准，首先，受到损失的是各国的标准团体（所谓“NB”），它们将失去一个开放的国际性（对话）论坛，继续进行OOXML标准化的完善工作；其次，微软的大批合作伙伴将可能失去商务合同，因为，微软没有ISO批准的文档格式。这些问题，我们暂且不说。如果OOXML失利，ODF也将被“拖累”，这是我们要明白的道理（或者叫“逻辑”）。此言的根据何在？理由如下：

1、目前，ODF的电子表格（不是它的1.2版本）缺少计算公式（formula）的定义，许多核心商务函数都没有定义，除了微软Excel的实际输出之外。这两者是相关的，如果微软Excel版本升级，将会导致ODF和OOXML的电子表格运算结果的“不一致”。那该怎么办呢？

2、目前，ODF还不支持许多微软文档格式的“遗留特性”，要是没有（ISO）标准化的OOXML，ODF将会失去这些“遗留特性”的权威定义（导致“无所适从”）。这必将延缓ODF对这些“遗留特性”的支持（指ODF的未来版本）。

3、目前，ODF还缺少一个相对于微软文档格式的“稳健映射”（“Robust mapping”），这就要求OOXML尽早完成这一ISO的标准化过程，如果OOXML不被（特别是ISO）标准化，谈何两者之间的“稳健映射”？

我认为，Patrick Durusau先生考虑问题的出发点是正确的（有道理的），如果不考虑全球近十亿人口的文档实际使用特性（所谓“遗留特性”），不考虑如何单凭ODF来实现对这些“遗留特性”支持的艰巨性，不考虑ODF的进一步完善的长期性，单从商业利害关系出发，就决定对OOXML的取舍（Yes或是No），是不妥当的，也是不公平的。

这就是我们所说的“如果OOXML倒霉，必然殃及ODF”论断的道理。实际上，微软寻求电子文档的“ISO标准化”（采用开放的XML语言来描述），对微软自身而言，就是一件非常冒险的事情。在这件事情上，微软虽是出自“好心”（指把电子文档搞成开放的“标准”，即便是有点不彻底性），但是，他却低估了竞争对手们（IBM、甲骨文等）完全出自商业目的的顽固对抗势力的巨大能量。如果微软这次“倒霉”，我是不会欢呼的。
原文请见:http://blog.csdn.net/yuanmeng001/archive/2008/03/26/2218315.aspx

据IBM
标准支持者谈 OOXML
一直以来，OOXML 规范不断受到一些人的指责和抵制，以至于很多人都想知道它究竟有什么缺点。本文将解释反对将 OOXML 作为标准的技术原因（而非政治原因）。
我在标准化领域工作了很长时间（包括近十年来在 ISO C 标准委员会的志愿者工作）。大多数对标准化感兴趣的人对于 Microsoft® 提出的基于 XML 的文档格式 Office Open XML (OOXML) 的标准化过程都有自己的看法。通常，我并不会撰文谈论自己的观点，但就最近 IBM 努力摆脱 OOXML 这一说法，我想表明自己的观点，但首先我要明确声明：我并不是 IBM 的员工，本文所述均是我本人的观点，并且这些想法与 IBM 在这一问题上的立场无关。
从很多方面讲，OOXML 标准确实是一种重要的规范。实际上，不论是否指责 OOXML 标准化过程中的政治因素，围绕它的标准化过程始终充斥着政治纠葛（参见 参考资料）。然而，抛开所有这些政治因素，还存在严重的技术问题，范围涉及 XML 是否是标准的最佳选择以及标准化的目的。所有这些内容都为我提供了很好的切入点，我还将谈论影响 OOXML 成为标准的因素。
标准存在的目的是什么？
标准存在的目的就是实现互操作。如果我的文字处理程序和您的文字处理程序可以打开相同的文件，那么我就可以轻松地与您共享文件。如果不能的话，就会产生麻烦。这意味着，在缺乏标准的情况下，我们将花费大量的时间和精力解决缺少共享文档格式的问题。文字处理程序供应商要花费令人难以置信的时间和精力研究彼此的文档格式，以便能够互相导入和导出文件，这样，用户才能在保存文档后打开它并加以查看。
很明显，几乎所有人都可以从标准中获益。而对于文档格式，惟一的例外是既定行业内占有主导地位的公司；实际上，缺乏标准对这些公司最为有利，因为它们可以将自己的格式推广为事实 标准。这样将使它们具备双重竞争优势；所有人都必须花费额外的时间和金钱支持这种格式，并且任何人的支持都不会是最好的。
需要注意的一点是，按照定义，一个良好的交换标准不会指定每一个供应商执行的所有事情。每个供应商必须支持标准中的所有特性，这也就意味着添加到标准中的每一种特性都要被大量供应商重复处理。最好能够支持不能以标准格式在文档中编码的扩展或额外的特性。作为一名用户，我宁愿拥有一个能够在任何位置可用的标准文档，而不是一个结构非常复杂的规范，使两个供应商不能彼此配合对方的行为。
对办公文档格式进行标准化的要求非常强烈。从公司到政府等众多组织都制定了诸多规则，要求软件支持面向文档存储的开放标准。人们都不希望受制于单个供应商；标准提供了方法摆脱这种限制。从这些方面考虑，我们来审视一下 Microsoft 提出的 OOXML 标准存在的技术问题。
OOXML 标准
OOXML 标准源于 ECMA，是一组以 PDF 形式发布的文档，共 6000 页左右。它包含了大量规范，内容涵盖了很多方面。该标准之所以如此庞大，是因为 OOXML 几乎完全复制了 Microsoft Office 应用程序在文件中可能保存的所有数据块。
一直以来，对 OOXML 技术方面的抱怨不绝于耳。所有指责最后都可以归结到最基本的一点：OOXML 并没有指定恰当的通用交换格式，相反，它指定了 Microsoft Office 的整个特性集，内容具体到 bug 兼容性。这为其他实现者制造了难于实现（事实上也不可能实现）的负担，而另一方面，OOXML 标准的内容却是 Microsoft 已经附带的特性。这引起了众多问题。
请不要将此误解为仅仅是对 Microsoft 依仗自身已有特性获得竞争先机的指责；如果 Microsoft 实现的是一个小型的经过良好设计的标准，并且所有人都可以适当实现，那么我们完全可以接受该标准。这些受到指责的问题可归结为三大类：一些特性的实现非常困难，而另一些特性则没有进行充分的说明，还有一部分特性完全属于 Microsoft Office 独有。这三类问题存在一定程度的重叠，但是每一类都代表一种不同类型的障碍。
要求不切实际
一般来讲，在标准中，实现者期望解决的问题已经得到了适当定义并确定了范围。您可能需要调整一些段落，但是所有内容都进行了指定，并且适当限制了范围。相比之下，OOXML 提出的要求缺乏明确性。例如，当描述页面标题时，提议的 OOXML 规范规定 “字体名 和字体类型 可以是本地化的值”。这个句子看似简单，却增加了问题的复杂性（由 Stéphane Rodriguez 指出。参见 参考资料）。
您可以使用哪些地区语言？您是否具有一个完整的地区列表，其中包含了其他供应商实现该规范使用的所有地区？您是否了解对字体名或字体类型实现本地化所采用的所有方式？如果一个热心的实现者选择一种您在实现时闻所未闻的语言编写字体名和字体类型，该如何是好？
这大致反映了一种基于历史经验的决策，根据它存储提供给用户或由用户挑选的本地化值。遗憾的是，如果没有详细的说明（至少要提供允许的完整地区列表以及告知正在使用哪个本地化），则不可能实现这一点。这反映了给定实现的特殊行为；对于要在多个实现之间共享的标准化格式，这并不是一种合适的选择。
说明不够充分
由于某些 Microsoft Office 文档使用以向量语言 VML 绘制的图形，OOXML 说明了如何保存这些图形的方式。这意味着所有实现者都必须阅读这些图形 — 遗憾的是，为他们提供的说明不够详细。您可以在特定项的内部查找字符串形式的 VML。
哪些值是真正被允许的？答案非常明了；“这个属性的可能值由 XML Schema 字符串数据类型定义”。这就是说，它是一个字符串。它可以包含任意的文本，其含义 只能由 VML 库的代码解答。简言之，除非您碰巧使用了 VML 库，否则不可能实现这个要求。
同样，这也是一种特殊行为。在针对交换设计的标准中，需要对图形的格式（可能只有一种）进行完整说明，并且要求使用另一种绘图库的实现者将图形导出 为标准格式。相反，OOXML 仅仅提供了对早期设计的摘要重述（并且有意设计为不能用于其他人），并要求所有人都适应它。
独有的特性
最后一类问题最让众多标准专家感到恼怒。这并不是由于它更加难于实现 — 最困难的实现莫过于根本就不可能实现 — 而是因为本来就不应该存在。这一类特性从某些方面来说完全依赖于 Microsoft Office。
也许最为人熟知的一个例子就是 OOXML 提供的一个可选设置。这个设置被称为 “useWord97LineBreakRules”，它指明要使用针对 East Asian 文档的 Word ‘97 中使用的换行规则。与前面的例子非常相似，任何人都不可能做到这一点，因为没有提供有关这些规则的任何说明。事实上，OOXML 标准甚至警告实现者不要实现这个规则：
清单 1. OOXML 标准关于 useWord97LineBreakRules 的指导说明
[指导说明：要如实地重复这一行为，其他应用程序必须仿效这个应用程序的行为，这其中涉及很多可能的行为，因此本 Office Open XML 标准不作一一介绍。如果应用程序希望匹配这一行为，它们必须利用并复制这些应用程序的输出。建议应用程序不要特意复制这种行为，因为其输出可能导致问题，并且维护此规则的目的仅是保证与应用程序现有文档的兼容性。]
这段说明真是妙极了。它没有提供关于这个特性的任何有用说明，并且反对实现这个规则，并解释了人们为何不应实现它。但是，等一下，如果不应实现这个规则，为什么还将它列入规范中？保证与现有文档的兼容性并不足以解释为何向一个以交换数据为目标的标准添加这个特性；用户担心的是能否在其他程序中打开他们的文本，而不是每个换行是否位于相同的位置！
这个特性之所以出现在规范中，是因为 OOXML 并不是一个文档交换格式；而是对 Microsoft 以前的二进制格式的精确重复，只不过用尖括号括起来而已。
这是否意味着 XML 并不是一种良好的选择？
听取了对 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 时，我很自然地参考了一种包含 “ff ff 00 03 [. . .]” 的 XML 格式的概念。在我写它的时候，我自己都觉得有些可笑。但现在看来并非如此。
原文请见:http://www.ibm.com/developerworks/cn/xml/x-ooxmlstandard.html?S_TACT=105AGX52&S_CMP=techcsdn

据cnBeta
据国外媒体报道,Open Document Format(开放文档格式,以下简称ODF)编辑帕特里克·杜鲁桑(Patrick Durusau)于近日发布了一封公开信.在信中,杜鲁桑强烈支持微软的Open Office XML(以下简称OOXML)文档格式成为国际标准,并表示ODF与OOXML一荣俱荣,一损俱损.
杜鲁桑写道:“作为OpenDocument文档格式的一名编辑,我希望推广OpenDocument,发扬它的优点,并尽可能地扩大其使用范围.”他表示,如果微软OOXML失败,这也就意味着OpenDocument的失败.而如果OOXML能够通过ISO的考验,那么OpenDocument也将因此而受益.
此前,杜鲁桑曾呼吁正反双方共同合作,而这封支持OOXML的公开信则更加强烈地表明了他的态度.杜鲁桑称,ISO再次否决OOXML不会带来什么好处.他说:“目前OpenDocument文档还没有统一的电子表格规范.电子表格中很多核心的财务数据只能通过Excel来导出.而导出结果也会因Excel的版本不同而有所区别.如果OpenDocument和OpenXML就这些数据得出不同的结果,怎么办?”
目前,ISO的成员们正在考虑是否认可并接受OOXML为国际标准.OOXML文档格式的批评者称,该文档格式为微软私有,因此不能成为标准.ISO成员表决意见的截止日期为3月29日.
作为微软OOXML的竞争对手,ODF是IBM所支持的开源文档标准格式.微软曾指责IBM一手策划了针对OOXML的攻击,并表示如果不是IBM从中作梗,OOXML已经获得了ISO的批准.

据cnBeta：
ISO代表开审微软OOXML 3月底就国际标准表决
本周政府专家们将在日内瓦国际标准化组织(ISO)举行会议,微软的Office Open XML文档格式的命运也将由出席此次会议的代表们决定.OOXML的支持者称它应当成为国际标准,而反对者则称微软OOXML成为标准格式会侵犯数字时代 人们的自由选择权.与会代表们不会在为期五天的会议上就OOXML的命运直接得出一个“是”或“否”的结论.他们将有一个月的时间来修改他们于9月份做出 的的决定.去年9月份,微软的提案只获得了53%的赞成票.此次,与会代表们要查看微软长达600页的技术规范文本中是否存在技术问题.投票期将会一直持 续到3月底.
两年半以来,微软一直在寻求使OOXML得到国际标准化组织认可的方法.上周微软还专门召开新闻发布会,宣布将部分公开产品的源代码,提高其畅销软件产品的开放和透明度,以推进行业竞争对手和客户的互操作性.为了应对欧盟的反垄断审查,微软将为 Office 2007中的Word、Excel和PowerPoint应用程序设计新的API,让开发商能够嵌入更多文件格式,也使用户能够将包括ODF在内的文档格式设置为他们保存文件的默认格式.
微软Office系列的产品经理格雷·诺尔顿(Gray Knowlton)重申,微软认为OOXML、ODF与其它格式均可共存.他说:“我们以前就说过,微软OOXML的目标与ODF、PDF或UOF都有明显的不同.我们希望产品功能能够与OOXML能否成为标准分割开来.在我们看来,这应该是两个不同的内容.”
甚至一些微软的竞争者也同意这一基本观点.例如,Novell就同时支持ODF和OOXML.ODF标准的编辑帕特里克·杜鲁桑(Patrick Durusau)也于上周表明立场,呼吁ODF与OOXML(PDF)共同发展.
但是OOXML仍然受到来自各方的强烈批评.批评者称,微软人为地操纵标准化进程向着对自己有利的方向发展.微软的竞争者IBM就表示,OOXML存有技术缺陷,而且应当采用单一文档标准.还有批评者称OOXML并非真正开放,而是由微软控制的.ODF支持者安德鲁·尤普德格罗夫(Andrew Updegrove)于周日发表文章呼吁国际标准化组织应该出于政治和社会原因而投票反对OOXML.他写道:“互联网已经成为非常核心的服务内容,而行使基本的公民权和人权都越来越多地依赖于平等、开放地享有这些核心服务.”
不过,根据国际标准化组织的规定,即使此次微软未能通过考验,这也并不意味OOXML申请标准道路的终结.微软可以再次提出申请.

倪光南谈OOXML再冲国标：建议中国仍投反对票
2月26日消息，针对下周开始的微软下一代文档格式标准OOXML进入国际标准的投票，中国工程院院士、国产文档格式标准UOF的推动者倪光南昨晚撰文建议中国本次投票依然投发对票，并提出微软OOXML与UOF及已经成为国标的ODF融合成为一个标准的新观点。微软上周五发布了新的拓展互操作性的战略，其中一项重要内容涉及下一代文档格式标准。微软公司称，将为用户提供多种文件格式的选择，微软将在服务包2(SP2)中为OFFICE 2007设计更多的应用程序接口，让开发者能够插入其他的文件格式，使得用户用户能够将这些格式作为保存文件时的默认格式。
微软中国董事长张亚勤博士特意举微软OOXML(Open Office XML)与国产UOF(Unified Office document Format)的例子说，微软公布了OFFICE 2007的API之后，UOF可以嵌入进去，用户不需要经过翻译器，就可以选择将UOF作为保存文件的默认格式，因此这一措施将惠及UOF，也是帮助UOF走向国际的措施之一。
除了本次的开放API外，微软还资助北航开发了UOF与OOXML之间的转换器。
倪光南撰文指出，微软OOXML现在正在修正长达2293页超过1000个的缺陷，现在的OOXML已与当初提出时有很大的不同，而这些重大变化根本还来不及进行评议，如果近期投票通过成为国际标准，显然是不严肃的，因此他建议中国在本轮投票再投反对票。
对于OOXML的未来，倪光南建议，微软OOXML与UOF及ODF融合成为一个标准，“既然ODF已成为国际标准，UOF已成为中国国家标准，ODF方面又表示愿意由‘中国领导实现两种标准的融合’，因此，人们希望OOXML也参与进来，共同制定一个融合的标准。如果有了这样的愿望，技术上的困难总是可以克服的。”
倪光南还指出，中国UOF的当务之急是推广，“通过以UOF取代老的文档格式事实标准，中国可以将文档信息资源的控制权掌握在自己的手中”。
以为下为倪光南院士撰写的文章全文：
倪光南：关于文档格式标准等问题的新建议
　　文/倪光南
一、希望微软能作实质性的开放
　　对于最近微软重视互操作性问题的一些举措，我们表示欢迎。由于微软在桌面操作系统、办公套件等方面掌握了事实标准，为了实现互操作，它首先就应当将这些事实标准完全开放，使竞争者可以开发兼容的软件，否则，对于竞争者而言，就是一种不公平的竞争，而互操作性也就不可能真正实现。
　　最近，微软“开放”了Office二进制文档格式，这是一个进步。但据有关的国产Office公司，如永中、中文2000等公司的分析，它的“开放”性是不够的。例如PPT文档只开放了微软Office某些版本的格式，而不是开放全部版本的格式，一些关键信息也无法找到(如宏信息、加密算法、嵌入字体信息等)。有人尝试按照微软公布的二进制说明文档去做，却始终无法生成有效的文档。所以，我们希望微软能作实质性的开放。
二、对Linux的专利威胁仍未解除
　　微软领导人曾说，Linux侵犯了微软的235项专利，这对Linux构成了专利威胁。虽然微软最近“承诺不起诉那些为开发和非商业分发用途而使用这些协议的开源开发者”，但对于其他企业仍然要求“获得专利许可”，而相应的许可条件并不清楚。我们希望，微软能明确宣布不对Linux提出任何专利侵权诉讼，而且应当覆盖Linux用户、开发者和企业等等，以彻底解除对Linux的专利威胁，从而在操作系统领域形成公平竞争，这样，才能真正实现互操作性。
三、中国的UOF标准已得到国际认同
　　现在，中国国家标准UOF已得到国际认同，包括作为国际标准的ODF方面以及作为ECMA标准的OOXML这二个方面，他们都表示支持UOF，支持UOF成为国际标准。ODF方面的合作方案比较具体，他们写信给中国有关部门，邀请中国政府与他们“共同协作，以实现两种标准，即开放文档格式ODF和标文通UOF融合为目标，推动在OASIS建立技术委员会为中国领导实现两种标准的融合”提供机会。OOXML方面还没有拿出具体的合作方案。
　　关于微软资助开发OOXML与UOF之间的转换器问题，我们的观点是：根据过去的经验，转换器是很难做的，如果做得不好，用户不会使用，如果最后做好了，能100%地转换，那么用户也会要求先将格式转换好了再存文件，最终还是只会存在一种格式，这正是为什么文档格式在过去只存在一种(即微软的事实标准)的道理。
　　既然ODF已成为国际标准，UOF已成为中国国家标准，ODF方面又表示愿意由“中国领导实现两种标准的融合”，因此，人们希望OOXML也参与进来，共同制定一个融合的标准。如果有了这样的愿望，技术上的困难总是可以克服的。
四、对OOXML的建议
　　目前，微软仍然坚持要将OOXML推为国际标准。虽然OOXML的制订过程很仓促，在去年9月ISO的投票中没有通过。前一时期世界各国对它共提出了3522个问题(后来合并为1000多个)，指出了OOXML中已发现的各个技术缺陷和错误等等问题。后来OOXML方面给出了一个2293页的答复报告，它承认了所提交的众多问题，并试图修正这些错误。但由于问题太多，时间匆促，看来，许多修正(有人估价达到1/4左右)是很粗略的或不适当的，甚至有的修正还产生了新问题。
　　考虑到OOXML有长达6000页的指标说明，现在又加上一个长达2293页的文件对超过1000个缺陷进行修正，OOXML已与当初提出时有很大的不同了，而这些重大变化根本还来不及进行评议，在这种情况下，如果匆忙地将它通过成为国际标准，显然是不严肃的。
　　因此，建议维持原来的投票结果，对OOXML不予批准。今后，建议它或是与ODF、UOF进行融合，成为一个新的国际标准，或是通过ISO的正常程序上报，给以充分时间使它走向成熟。
五、当务之急是推广UOF
　　事实表明UOF和ODF、OOXML处于同一水平，这说明在信息领域容易实现跨越式发展，在推广基于XML的新一代文档格式方面，中国完全可以走在其他国家的前面。现在，国产Office厂商和有关机构正在紧张地进行测试，以保证国产Office能提供对UOF的支持。至于微软资助开发的“转换器”则还没有达到能提供测试的地步，它支持UOF到何种程度现在还无从评估。
　　一旦国产Office通过了严格的测试，证明能很好地支持UOF了，就可以从公文应用开始，大力推广应用UOF。希望不久以后，通过以UOF取代老的文档格式事实标准，中国可以将文档信息资源的控制权掌握在自己的手中。

据cnBeta消息
上个月微软承诺将二进制旧Office文档格式技术细节开源,现在该工程已经进入实质性阶段.
SourceForge上已经出现了Office Binary (doc, xls, ppt) Translator to Open XML工程,提供开发转换程序.该工程目前仍处于襁褓期,因此目前只能看到开发蓝图.
但另一方面,在微软下载中心,原有的二进制文档格式资料均已经公开.
“Office Binary (doc, xls, ppt) Translator to Open XML” 工程
sourceforge: http://b2xtranslator.sourceforge.net/

二进制文档信息主页
http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx

Word 97-2007 Binary File Format (.doc) Specification PDF | XPS
PowerPoint 97-2007 Binary File Format (.ppt) Specification PDF | XPS
Excel 97-2007 Binary File Format (.xls) Specification PDF | XPS
Office Drawing 97-2007 Binary Format Specification PDF | XPS