The Standards Blog

Microsoft Posts XML Reference Schema FAQ (and Thumbs Nose at ODF and Sun)

OpenDocument and OOXML

Microsoft has posted a Q&A that is mostly reassuring, and partly flagrant FUD

Microsoft has posted an FAQ at a public page of its website titled Ecma International Standardization of OpenXML File Formats Frequently Asked Questions . The intro to the FAQ reads as follows:

We have been gratified to see the general positive reaction to the Microsoft move to standardize the OpenXML document formats. Public sector organizations and many other customers as well as those in the technology industry continue to praise this development as they become aware of the details. The announcement was very straightforward, but as we have spoken with more organizations we are collecting the questions that arise about the details and implications of the announcement.

The page also promises regular updating, to "make sure that everyone has access to more and more information."


The answers you will find range from expected, to genuinely reassuring, to what I believe are clearly inaccurate statements about ODF. The highlights are as follows:


1. Microsoft has clarified some important points relating to its covenant not to sue: no license will be required, and a "conformant" implementation does not mean that the entire specification must be implemented. However, this also means that extensions will be permitted.


2. Microsoft has confirmed that the same covenant not to sue that it has offered regarding the current version of Office will also apply to Office 12 and to the eventually approved Ecma standard.


3. Based upon what I have been told in interviews in the past, Sun's role in the development and relating to the release of ODF, and the development of ODF itself, have been blatantly misrepresented. I would be surprised if Sun does not make a strong statement in response, and hope that they will do so.


With the flagrant exception of the ODF statements, most of the answers are reassuring, and some are meaningful. But the gratuitous and false statements about Sun, ODF and OASIS add a jarring note that represents at best a PR gaffe, and at worst an indication of the degree to which Ecma may allow Microsoft to write the script for the standards process to be conducted in its name.


Here is my initial take on the more important information to be gleaned from the FAQ, by category of information. I may add additional analysis at a later date in this, or in a new blog entry:


1. Text confirming the tight focus on producing a standard that is locked on Microsoft Office:

Q: Why has Microsoft taken existing document formats and moved to standardize them with industry partners, rather than develop something new in a more collaborative process?


A. Organizations all over the world have asked Microsoft to insure that their valuable investments in billions of documents are protected and are made even more valuable by enabling conversion to modern open XML-based formats.


By taking this approach to standardization with industry participation and support in Ecma International, organizations around the world will have the immediate benefit of both backward compatibility for existing documents and the long-term benefit of a forward-looking open industry consensus process.

Other Q&A's stress the degree to which the submission is intended to optimize the user experience for those using Office.


2. Mildly reassuring statements such as the following:

Q: How open or closed will the Ecma International process be for the OpenXML formats?

A: …The Ecma organization will focus on fully documenting the formats to enable further standards work, to insure cross-platform and multiple tool support and to meet widespread industry requirements and utility. Then it will go still beyond this startup mode under the stewardship of Ecma member organizations working on the technical committee. We expect competitors, partners, and customers to embrace the OpenXML formats as a result.


This makes the right noises, but it is not clear how much flexibility will be allowed in the ongoing work, given the tight initial focus on locking on Microsoft Office. It would seem odd to show so much commitment to optimizing the format for Microsoft in the beginning, and then ignore those "billions of pages" of documents in future releases of the same standard.

3. Outright untruths: I am outright shocked by a portion shown below of the answer given to the following question:

Q. Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product (sometimes called ODF)?

A. Sun submitted the OpenOffice formats to a small committee in the OASIS organization. The record shows that there were almost no material changes to the OpenOffice specification from the time it was submitted to the time it was approved by the working group at OASIS. Sun timed the release of the OpenDocument standard in conjunction with the OpenOffice 2.0 release. The OASIS committee did not focus on the requirements, constraints, and experiences of Microsoft customers.

From what I have been told in interviews I have personally conducted in the past, every contention (but one) in this statement is false. Moreover, the statement about the composition of the formats going into the process and coming out can easily be tested.


Here's an extract from a story I wrote in September, based on interviews with those in the know at Microsoft, OASIS, Sun, Peter Quinn, and management of a trade association critical of the Massachusetts decision. I'll do my own Q&A here, using excerpts from that article as answers:

Q: How small was the "small committee?"


A. OASIS chartered what was originally called the OpenOffice XML Format Technical Committee (TC) in December of 2002. The original members of the TC were nothing if not diverse: Arbortext, Boeing, Corel, CSW Informatics, Drake Certivo, National Archive of Australia, New York State Office of the Attorney General, Society of Biblical Literature, Sony, Stellent and Sun Microsystems. Later, other organizations joined the committee, including KOffice and IBM, each of which has created its own office suite that supports OpenDocument. Some, but not all, of the suites that support OpenDocument are based upon open source software developed by, which continues to offer an open source office suite that is committed to compliance with the OpenDocument OASIS Standard.


Q. Is it a fact that " there were almost no material changes to the OpenOffice specification from the time it was submitted to the time it was approved by the working group at OASIS?"


A. The new TC did not simply begin where left off, but instead spent more than a year analyzing the existing format in detail in order to determine what to retain, what to change, and what to add, thereby ensuring that the finally adopted standard would be vendor neutral, application independent, and as interoperable as possible. More than a year of additional work was required to take the resulting format to a third and final vote by the TC in March of 2005. The draft standard was also posted for public review during the process, and the many comments received from non-members were reviewed for merit and inclusion by the TC. The resulting OpenDocument 1.0 was approved by the full membership of OASIS two months later, becoming an OASIS Standard in May of 2005.


Q. Did "Sun time the release of the OpenDocument standard in conjunction with the OpenOffice 2.0 release?"


B. A. . The resulting OpenDocument 1.0 was approved by the full membership of OASIS two months later, becoming an OASIS Standard in May of 2005. [Note: OASIS is an organization with hundreds of members.] The one statement that I assume is at least partially true is this: "The OASIS committee did not focus on the requirements, constraints, and experiences of Microsoft customers." This would have been difficult to accomplish, since Microsoft, although it was an OASIS member, chose not to become a member of the ODF Technical Committee.


4. Statements on Licensing: Here are the most important statements:

There is no longer really a license that people need to sign up for in any way — No one needs to sign anything or even reference anything. Anyone is free to use the formats as they wish and do not need to make any mention or reference to Microsoft. Anyone can use or implement these formats to both read and write the formats with their technology, code, solution, etc.

This was expected, but not completely clear from the Microsoft Website.

Transferability of solutions and "GPL Compatibility" — If someone wants to build a solution that works with our formats, they are free to do so without worrying about patents or licenses associated with our formats. The concerns raised with our previous license about attribution and sub-licensing are now eliminated. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but we believe we have removed the principal objections that people found with our prior license in a very simple and clear way.

Aside from the use of the word "principal" (which may not really mean anything worrisome) this is reassuring.



Subsets, supersets, and 'conformance' — Anyone is free to work with a subset of the specifications, and anyone is free to create extensions to the specifications. A 'conformant' use is simply one that does not modify the specification. Of course subsets and supersets may create incompatibilities with other uses of the specifications and we want to provide some guidance on this topic in the future, but this will be guidance and not a mandate. The key is that this is an assurance that no one will be sued for using intellectual property in the specifications as they are written.

This is important and meaningful, and answers one of the most serious concerns with the text of the covenant as earlier released.




Summary: this is a good start, the misstatements aside. There are a few further questions that need to be asked, such as whether Ecma has agreed to limit the future scope of the standard to track Microsoft Office, or whether the Technical Committee that maintains could eventually evolve it into a truly open, vendor neutral standard.