I will be curious to see if the Burton Group corrects any of the factual errors now being pointed out, which seem abundant. And I will be curious to see if they do so before the February 2008 ISO ballot on OOXML. After all, one of the co-authors of the Report, Guy Creese says, "We’ve made the overview available for free (I must admit I'm not sure for how long), as we believe this topic warrants expanded industry debate before a February, 2008 ISO ballot on OOXML, and we want to help catalyze and advance the debate."

If that is the sincere goal, they surely desire to correct the many errors made so as not to mislead anyone, and *before* the ballot resolution meeting. Otherwise, if FUD is the goal, they will do so afterwards, if ever.

Hey. Call me cynical. I'm a New Yorker. We've seen it all. And I see Microsoft pushing this report. The Burton Group may not know any better, but Microsoft surely can't plead ignorance of the facts.

You know what I hope? I hope someone shows the Burton Report to the EU Commission investigating Microsoft's behavior with respect to MSOOXML and interoperability. Why? Because as I read it, it seems to be at least implying that people should use MSOOXML because Microsoft is a monopoly, one which doesn't share its proprietary extensions, and so no one can render their documents as well as Microsoft can. Is that not the exact focus of the EU investigation?

The thing about a standard is you want it to be universal. That's the ideal if you are talking about an *interoperability standard*, and the hope behind any such standard. Proprietary, by definition, means it isn't universal. And in a standard regarding interoperability, it's shooting yourself in the foot. And that, of course, is what's wrong with MSOOXML.

That's not all that's wrong. I'd like to give you just a few of my impressions after reading the ODF Alliance paper, in my own simpler language, on points 1-6:

1. Burton's argument is that MSOOXML can "more faithfully recreate the look and metadata" but this is technically nonsensical. Both ODF and MSOOXML are formats, not applications. Only an application can recreate the look and metadata of a document. Microsoft Office can do that if Microsoft wants it too, but sometimes it doesn't want it to, as in the recent Office 2003 SP3 incident, or any time it decides not to support legacy features, like Microsoft recently stopping support for VB scripting in Office 2008 for the Mac. Now what are Mac users supposed to do? That's precisely the problem you have when you rely on or are dependent upon any proprietary vendor, and standards are supposed to free you from such events.

2. Burton claims Microsoft's OOXML is more extensible. But ODF is just as extensible as MSOOXML, except that there are no proprietary extensions that keep others from being able to interoperate. See number 1.

3. As for Burton's idea that OOXML's support for "custom schemas" makes it somehow "more ecosystem- and application-oriented than ODF", I'll translate what comes across to me as signifying codespeak, wink wink, or maybe that's how analysts talk. It's saying, to my eye, that because Microsoft is a monopoly and has a dominance, and because it has its own secret proprietary schemas, only it can possibly work well, so everyone should just opt for that. That, of course, leads us back to number 1 again, and also to the new EU Commission investigation of Microsoft as to whether it is deliberately refusing to let competitors interoperate sufficiently with its "custom schemas".

If so, if you enable a monopoly to remain one, are you helping yourself and your business, or just the monopoly? I think you have to ask yourself, what is an interoperability standard for? Isn't it precisely to try for universality? We're not talking about sending a photo in any number of choices of format here. There, the recipient merely has to be able to look at it. With documents interoperability, you need a lot more than that. And if your goal is to be able to open, edit and save those documents no matter what you or others are using, then a monopoly stranglehold may not be in your best interest, only in the monopoly's. See number 1.

4. Burton claims that calling it "Office Open XML" is being done by IBM and Sun to remind folks "of its origin in proprietary Microsoft Office file formats." They seem to imply it's some kind of dirty trick. That's the name Microsoft itself gave it. It might be a warning bell when analysts get facts wrong. How can they reach reliable conclusions from wrong facts? You might consider that enough to stop reading the Burton report.

5. As for Burton Group's allegation that folks are using the transition to XML to "more effectively compete with Microsoft Office," one simply has to ask, even if it were true, "What's wrong with that?" I certainly am not competing with anyone, and I care deeply about ODF. Why? I want to be able to share documents with family members and have them be able to read them, edit them, save them, and send them back to me, and vice versa.

Anyway, as in point 4, Burton has it backward. ODF vendors were the trailblazers here. Keep in mind, the ODF standards process began over 5 years ago in OASIS, and it's already an international ISO standard. Microsoft is following along with a spoiler candidate.

6. Burton calls ODF "somewhat simple" compared to OOXML. Smile. Being simpler than Microsoft's 6,000-page initial offering is probably not hard to accomplish. Nor is it a bad thing in a standard. Call it a feature, not a bug. You want people to be able to use the standard, after all. Many of the comments that the National Bodies' technical committees offered had to do with the sheer impossibility of even evaluating something so long and complicated in a short space of time. And they are technical experts. So, again, Burton Group has it exactly backward, I'd say.

They must not be tech guys. As the ODF Alliance puts it, "XML is simple. HTML is simple. Moreover, Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP) and other essential IETF standards are explicitly named that way because of their simplicity." Another word for simple, they suggest, is elegant: "There are considerable liabilities associated with unnecessary complexity: increased development and maintenance costs, increased difficulty to program, more complex (and therefore possibly negative) security implications, and generally buggier implementations."

I know. It's funny to go through the strained, totally backwards list, but it's worth reading the whole ODF Alliance response. There are other outright mistakes in the Burton Report, which would be worse if they are deliberate. Who knows? But it's totally false to say that "it wasn't possible for Microsoft to embrace ODF". They were on the OASIS Board of Directors, for heavens' sake, as ODF was being developed. They chose not to get involved for their own reasons, I suppose, but to say it wasn't possible is not true. They can even now, if they wished to. In fact, some country comments on MSOOXML asked them to please just merge the two, ODF and MSOOXML, so as to avoid two standards for the same thing.

As for the claim that ODF is "less compatible with the earlier binary Microsoft file formats", ask yourself why that might be, if it is so. For that matter, why can't MSOOXML do it either without extensions? If ODF was allowed to use those same extensions, it is just as capable of representing legacy binary formats. Ask Microsoft why they won't let that happen. Then read my point number one again and ask yourself where your best interest lies.

It occurs to me that this is a good place to tell you that Groklaw volunteer grouch and I have just redone Groklaw's ODF-MSOOXML permanent page, where you can find many resources and links to more information on this subject.

Just as a proof, here's a screenshot of the Burton Group website, where they call MSOOXML the same name that they scold Sun and IBM for using, Office Open XML:

*****************************

Open Document Format Alliance Response
to the Burton Group's Report

The Burton Group has recently released a report entitled "What's Up, .DOC? ODF, OOXML, and the Revolutionary Implications of XML in Productivity Applications"¹, written by analysts Peter O'Kelly and Guy Creese. This report makes a number of erroneously negative and unbalanced statements about the Open Document Format (ODF), many of them quite puzzling to us.

The Burton Group chose not to review their report before publication with the ODF Alliance, the foremost industry organization, with 480+ members in 53 countries, supporting the Open Document Format for governments. Had they done so, we would have brought to their attention a number of factual errors in the report, pointed out what in our opinion were weaknesses in the logic, and noted places where they may have inadvertently been misled by their sources.

The analysis that follows provides, on a page-by-page basis, 18 flaws with this report that we have identified so far. We raise, and clarify, these issues for the benefit of others, especially for the government officials with whom we work closely, who are evaluating their options to gain control over their documents and may be confused by some of this content.

1. Page 5 says "...[L]ibraries and large businesses, faced with storing and using years of Microsoft Office legacy documents, will prefer OOXML, as OOXML can more faithfully recreate the look and metadata (such as spreadsheet formulas) stored in Microsoft's binary file formats."

This statement confuses file formats and applications. Surely, OOXML cannot faithfully recreate the look of anything. It is a file format, not an application.

Microsoft Office is the application that interprets OOXML, and it can also render legacy binary file formats, except when Microsoft decides to remove support for them, as Microsoft recently did with Office 2003 SP3². There can be further problems when Microsoft decides not to support legacy features, such as when they removed support for Visual Basic scripting in Office 2008 for the Macintosh.³

The authors fail to note that no other application supporting OOXML has been able to faithfully or fully recreate the look of Microsoft's legacy binary documents. So the statement that OOXML a file format is the solution for rendering legacy documents is simply false.

1

Why does the report argue that OOXML is preferred over ODF for extensibility reasons, but fail to mention that ODF's extensibility features are just as rich? This lack of balance is disconcerting. ODF has extensibility features that are just as powerful as OOXML's, and, what is more important, ODF's features are based on existing industry standards, such as the W3C's RDF and XForms.

Further, it is not clear to us what the statement about not waiting for standards body to give their approval means. Surely the authors are not suggesting that we repeat the problems of some earlier efforts where multiple "user defined extensions" to a standard meant that we really didn't have a standard at all?

3. Page 5 also discusses OOXML's support for "custom schemas" and suggests that "OOXML is more ecosystem- and application-oriented than ODF."

We think it is unwise to consider exclusively Microsoft's particular "custom schema" feature. We should instead ask what the underlying business problem is that we are trying to solve.

For example, if you wish to programmatically update a stock price in a document (what the paper suggests is solved by custom schemas) then there are many other approaches, from custom spreadsheet functions, to document transformation, to DOM manipulations, to tagging, to mapping to an XML database, and so on. The underlying problem is how to take what is ordinarily unstructured document content and impose an organization's structured view on it. Suggesting that only Microsoft's custom schema support solves the problem, while ignoring ODF's support for alternative and standards-based approaches to the same underlying business task, is misguided, in our opinion.

In particular, the paper fails to note ODF's XForms support and how it can be used to enable users to add data to a document in a user-defined schema and then submit it to a web service. XForms is a W3C standard. ⁴ Here again, a sense of balance is missing, as is consideration of fully capable modern programming techniques that employ ODF to solve real business problems.

4. Page 5 says of the OOXML standard, in a section pointedly called "What's In a Name?: Innuendo," that "IBM and Sun reference it via its Ecma name of "Office Open XML" (as reminder of its origins in the proprietary Microsoft Office file formats)."

This is a curious statement, but there is no need to suggest the name is used for some

2

Speaking of names, nothing is said about Microsoft choosing a name for their specification which was obviously destined to cause continued confusion with ODF's first implementation, Open Office. ⁶

5. Page 12 says, "...[M]any Microsoft competitors have attempted to exploit the transition to open, XML-based file formats in order to more effectively compete with Microsoft Office. While some of its competitors have very little hope of establishing successful products that directly compete with Microsoft Office, they may still seek to disrupt Microsoft's business by making Office less profitable, thus depriving Microsoft of opportunities to use Office profits to subsidize product development efforts in other market segments."

The report seems to suggest that it is somehow improper to compete against Microsoft. We find that view puzzling and confusing. ODF vendors are not "exploiting" the transition to open, XML-based file formats. They were the source, the vanguard of the transition to open, XML-based file formats, having initiated standardization of ODF within OASIS over 5 years ago. Also, according to the authors' own statements earlier (bottom of page 6), OpenOffice has had 100 million downloads compared to Office's 500 million estimated users. How can it be said that there is "very little hope of establishing successful products that directly compete with Microsoft Office"?

ODF is the source for new innovation and is set to further extend the value of modern technologies that have profoundly affected users of the Internet. For example, the Wikimedia Foundation, the technology arm of the organization that brought us Wikipedia, announced that they will use ODF to produce publication-quality documents from Wikipedia entries. ⁷

6. Page 13 says, "ODF is currently somewhat simple (and simplistic) compared with alternatives such as OOXML".

The rather negative term "simplistic" is asserted with no backing argument or evident motivation. In our opinion, this does little to establish a sense of objectivity in the report. We might also ask when did "simple" became bad thing in a standard?

XML is simple. HTML is simple.

Moreover, Simple Mail Transfer Protocol (SMTP), Simple Network Management Protocol (SNMP) and other essential IETF standards are explicitly named that way because of their simplicity.

3

There are considerable liabilities associated with unnecessary complexity: increased development and maintenance costs, increased difficulty to program, more complex (and therefore possibly negative) security implications, and generally buggier implementations. A more balanced approach would have examined the negative effects of a more complex standard.

"As simple as possible, but no simpler" was Einstein's advice, and is worth heeding. You can always build complex applications from simple pieces, but you cannot easily build simple applications from complex pieces.

7. Page 13 says, "In terms of productivity application model concerns, ODF is primarily focused on content and presentation domains, and it is far less useful for scenarios requiring advanced structure and behavior capabilities. For example, ODF (currently in a 1.1 revision) supports a single table type for use within document, spreadsheet, and presentation applications"

The authors fail to make a convincing argument here, in our opinion. Taking a benefit of ODF and declaring that it is a liability, but without any argument, is puzzling. Most experts would say that, structurally, a table in a word processing document, a spreadsheet and a presentation share a number of factors in common that express their "tableness" such as an addressing mode by row and column, the ability to adjust row heights and column widths, the ability to have background colors, text content, etc.

Good analysis and and elegant design, (an art not a science, but still one with established norms) calls for common abstractions to be commonly represented. So the fact that ODF has a single table model is a virtue of the format, not a liability.

Note that there is nothing that requires the application to make a table in the user interface appear the same in all three applications. ODF is only defining the underlying storage model, and a table is a table is a table. There is no need for making this more complicated than necessary.

Conversely, examining why a single standard unnecessarily includes redundant representations of the same basic concept in three different areas would be very useful, if it can be justified. It would lend balance to the arguments presented. Such redundancy would tend to make a standard much longer than expected and increase the development complexity, unless you already happen to have an implementation.

8. Further on page 13 the authors state, "...it's essentially impossible to get ODF proposals approved if they're not also supported in OpenOffice.org, and further noted that Sun closely controls OpenOffice.org (much as it also holds control over Java)."

This is demonstrably false, and the use of unnamed "vendors" as sources does not eliminate the

4

First, on the control aspect, note that ODF 1.0, the standard, is owned and controlled by OASIS, a standards consortium of over 600 member organizations. Sun is just one company among many members. Indeed, for most of the development of ODF, Microsoft was on the Board of Directors of OASIS.

Second, OASIS is a corporation. It is legally bound to its Bylaws. There is no arbitrary control by member corporations.

The ODF TC is co-chaired by an IBM employee and a Sun employee, and is regulated by the OASIS TC Process document, which is publicly readable by all⁸ and has clear rules of procedure and appeal.

The ODF TC has three subcommittees. The Accessibility SC is co-chaired by IBM and Sun, while the Formula Subcommittee and the Metadata Subcommittee are each chaired by individual members of OASIS who are not affiliated with any large corporations.

Voting rights in the ODF TC, for accepting or rejecting features, is currently as follows:

• Sun -- 3 voting members
• IBM -- 4 voting members
• Individuals -- 3 voting members

This can easily be verified at the OASIS ODF TC website. ⁹

Is sharing the chair position on the TC and on 1 of 3 subcommittees considered "closely controlling"? Is having 30% of the votes considered "closely controlling"?

As for proposals being accepted into ODF, we note that all three major features for ODF 1.2, RDF metadata, OpenFormula, and enhanced accessibility, are new proposals which have not been yet implemented in OpenOffice. Moreover, the ODF TC is currently processing a set of features requested by the KOffice open source project. So the assertion that it is "essentially impossible" to get new features into ODF if they are not already supported by OpenOffice is not true. This error is unfortunate and needs correcting through rigorous fact checking, as do the others, in our opinion.

Oddly enough, this particular error occurs in several places. A search of the report for the word "control" shows it used six times, once in reference to "Chinese communists" and five times in reference to Sun Microsystems.

Note, however, that no mention is ever made of the strong direct control Microsoft asserts over OOXML, its having sole chairmanship of the Ecma TC45, and its having secured a committee charter that prevents any changes to OOXML that are not compatible with Microsoft Office.

5

9. On page 14 the authors state, "Note that it wasn't possible for Microsoft to embrace ODF during this period, as Microsoft's investment in XML file formats was long underway before ODF became an OASIS standard in 2005 (and because of Microsoft's need to maintain compatibility with earlier Microsoft file formats)."

This contradicts the author's own presented timeline. The ODF Technical Committee was created in OASIS back in 2002. There was clearly ample opportunity for Microsoft to join and influence the evolution of ODF. Since Microsoft was on the OASIS Board of Directors, they had significant opportunity to both know about and participate in what was happening in the development of ODF. It's unfortunate that they chose not to lend their expertise to this industry community effort.

10. Page 16, says "Since ODF is less compatible with the earlier binary Microsoft file formats than OOXML, file format translations involving ODF can result in the loss of file fidelity, a constraint that limits ODF's utility for organizations that need to support file-based workflow involving Microsoft and non-Microsoft applications."

The statement that ODF cannot represent the contents of legacy documents with full fidelity is false. Further, it ascribes a fault to ODF as a format that is really an application issue.

ODF, using the defined extensibility mechanisms in the ODF standard, can represent everything in Microsoft's legacy binary formats. What in practice makes this difficult is that the proprietary legacy document formats are poorly documented and have been historically withheld from competitors.

On the other hand, OOXML itself cannot represent all legacy formats without extensions. Extensions are required for features such as scripts, macros, DRM, etc., as the authors point out earlier in the report in reference to .XLSM documents. But if ODF can use extensions, it is just as capable of representing legacy binary formats as OOXML is.

11. Page 17 says of the OpenDocument Foundation, that "It was unable to successfully address requirements for capabilities related to workflows with Microsoft Office applications, however, and parted ways with the OASIS ODF-TC after it failed to gain approval for several proposals designed to make ODF more capable for addressing full-fidelity file format operations involving Office clients."

This statement is misguided in its omissions. First, the authors failed to note that the ODF TC evaluated the Foundation's proposals at great length, and were not persuaded that these changes would in fact bring the fidelity benefits claimed by the Foundation. Second, even some former Foundation members, when put to a vote, disapproved the proposal. Third, the vote was not against interoperability. It was an evaluation by the technical experts on the TC that the proposal would not work.

6

It would have been interesting for the report to give a historical examination of compatibility of Microsoft's legacy document formats between the various implementations of Microsoft's own software. Have users always had full-fidelity compatibility between these releases? Also of interest might be an analysis of what happened to users who decided to employ Microsoft's Office 2003 XML format, now deprecated.

12. On page 17, the report says, "Despite all of the debate and controversy surrounding ODF and OOXML, it's important to recognize that the standards organizations are working as designed, and that both the standards and the organizations are constructively evolving as a result." And later on that same page, "It's likely ISO will revise its procedures to prevent similar disruptions in the future, so in some respects the OOXML episode will produce some useful stimulus/response improvements within ISO."

This statement misses the point. The question is not whether the organizations' procedures are perfect or not. No matter how well intentioned a process is, loopholes can always be found. Sometimes they are small, sometimes they are huge, but in all cases exploiting those loopholes is nothing less than contradicting the spirit of the process. The authors fail to consider the numerous articles highlighting how those loopholes have been exploited, and the spirit of the process subverted by stacking committees, by offering marketing consideration to business partner members who voted in favor of OOXML, and by overloading fast track processes with proposals that are of extraordinary and unsuitable length.

The statement that this is all useful and constructive because it will be a stimulus to improvement within ISO is patronizing of ISO. It ignores the basic issue: wouldn't it have been better to have avoided the extreme exploitation of process loopholes and followed the path of previous interpretations of the spirit of the processes as others have done in the past?

Also see the article "Sweden's SIS Declares OOXML Vote Invalid - Will Change Vote from Yes to Abstain - Updated. ¹⁰

13. At the bottom of page 17, the authors present a list of prior protocol and API disputes with Microsoft, such as VIM, IDAPI, OpenDoc, etc., and suggest, "In these and other earlier encounters, when Microsoft's competitors sought to collectively compete with Microsoft by leveraging standards, the everybody-but-Microsoft standards have generally failed to achieve significant market momentum."

The examples given are ancient history. Also, note that VIM (1993), IDAPI (1992) and OpenDoc (1992) were not formal standards. The report fails to note that the market has evolved in the past 15 years and that that customers are better educated in the liabilities of vendor lock-in, and are now more aware of the important role that open standards play in ensuring

7

In our opinion, it would be far better to look at the example of Internet and web standards to see how Microsoft's competitors, and Microsoft itself, have succeeded. ODF has the potential to be the same competitive force for office productivity applications, using the same standards-based approach.

14. On page 18 the authors introduce a section by saying, "If productivity application evolution had peaked around the feature set of Office 97, and if there weren't exabytes of files captured in earlier Microsoft Office file formats, it's possible that ODF could have succeeded as a global standard for productivity application file formats."

This point is not argued, it is just asserted, without any supporting evidence. We suspect that many of the arguments being made today in the report for Microsoft and against ODF would also have been made in 1997 had we been in that situation then. The network effects were smaller, but they were big for the time.

15. Later on page 18 the authors state, "OOXML will be more pervasive than ODF for several reasons. It's a better form-follows-function fit for most productivity application usage patterns".

This is a bold claim without argument or analysis to back it up, as far as we understand it. On what basis is the assertion that more than 50% ("most") uses of documents cannot be represented in ODF? We believe, for example, that the entire Burton Group report could be represented in ODF without any loss in fidelity. Do the authors believe that more than 50% of the documents in use, today and legacy, are more complex than their 37 page report?

16. Further on page 18, the authors note, "OOXML will gain market momentum as vendors such as Altova and Mindjet introduce products that support OOXML. Altova, the leading vendor of tools for XML-focused developers and designers, added OOXML to its XMLSpy product line in 2007."

This statement misrepresents market momentum by citing niche application support. While they may be fine products, will it really be the case that an XML programmer's editor and mind map software will drive the adoption of an XML office document format like OOXML?

Will someone in a university or a business office adopt OOXML as a word processor format because they can edit it in Altova? That would be remarkable, considering the relatively small percentage of all end users who edit XML at that level. MindJet already supports the legacy binary Office formats. By what mechanism does MindJet supporting OOXML cause someone to move to OOXML?

Certainly, if a user wants to move to OOXML, having this support removes a potential obstacle to migration. But it alone can do nothing to cause market momentum. We believe, in fact, that

8

17. Page 19 says that "ODF represents laudable design and standards work. It's a clean and useful design, but it's appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn't a requirement."

The authors here contradict their own argument. On page 8 they stated, "In many cases, the productivity application file is ephemeral, used only to present and capture user actions for business transactions that are ultimately captured in enterprise systems rather than stand-alone productivity application files (that is, the files are destroyed when the transaction is complete and captured in other systems of record)." We believe, and follow the practice of, authoring a document in ODF and publishing it as a PDF file. For us this is a not an "unusual scenario" nor does it necessarily involve "full Microsoft Office file format fidelity."

Further, what does "full Microsoft Office file format fidelity" even mean? This seems like a circular argument, that ODF is only useful in cases where you are not using Microsoft Office file formats.

18. On page 21, the authors claim, "Even Adobe's own Buzzword service will likely add support for OOXML--again, if only for Office 2007 file compatibility."

This tells only half the story, again. Adobe has stated publicly that it plans on adding ODF support. ¹² The cherry-picking of statements, ignoring positive facts about ODF, while speculating on positive futures for OOXML, is puzzling and goes against the paper's claimed position of objectivity and vendor neutrality.

There are also issues not raised that cause concerns. For instance, why is there no discussion on accessibility issues raised by the disability community with respect to office documents? These issues have raised worldwide consciousness of the impact of information technology decisions and standards on the lives of people with disabilities. We hope it is not because the authors did not wish to acknowledge either (1) the issue's importance, or (2) that ODF v1.1 has established a new high water mark for document formats, a high water mark that should not be allowed to recede with the acceptance of anything less from any other office document format. ¹³

We believe every statement in this report should be re-examined to ensure that it is fully balanced and has taken in the views of all relevant stakeholders. In this quick review, we believe we have shown that the analysis is incomplete, at times misguided, and selective. Please review this paper critically along with "Achieving Openness: A closer look at ODF and OOXML" ¹⁴ and come to your own conclusions.

9

¹ http://www.burtongroup.com/Guest/ Ccs/WhatsUpDoc.aspx

² http://www.eweek.com/c/a/Windows/
Microsoft-Takes-Heat-for-Office-2003-SP3-File- Format-Blocking/

³ http://www.macworld.com/article/ 54320/2006/12/microsoft.html

⁴ http://www.w3.org/ MarkUp/Forms/

⁵ http://www.microsoft.com/interop/ osp/default.mspx

⁶ http://www.robweir.com/ blog/2007/ 01/amusing-but-still-confusing.html

⁷ http:// wikimediafoundation.org/ wiki/Wikis_Go_Printable

⁸ http://www.oasis-open.org/committees/ process.php

⁹ http://www.oasis-open.org/ committees/membership.php?wg_abbrev=office

¹⁰ http://www.groklaw.net/ articlebasic.php?story=20070830155109351

¹¹ http://publications.becta.org.uk/ download.cfm?resID=35275

¹² http://www.adobe.com/ special/buzzword/faq.html

¹³ http://atrc.utoronto.ca/ index.php?option=
com_contect&sectionid=14&task= view& hidemainmenu=1&id=371

¹⁴ http://www.onlamp.com/pub/a/
onlamp/2007/06/14/ achieving-openness-a-closer-
look-at-odf-and-ooxml.html?page=1