‘I don’t know what you mean by “glory,” ’ Alice said.
Humpty Dumpty smiled contemptuously. ‘Of course you don’t — till I tell you. I meant “there’s a nice knock-down argument for you!” ’
‘But “glory” doesn’t mean “a nice knock-down argument,” ’ Alice objected.
‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone, ‘it means just what I choose it to mean, neither more nor less.’
‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’
‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’
— Lewis Carroll from Through the Looking-Glass (1871)
I have written about Microsoft’s language games previously. These games continue and it appears to be time for yet another inoculation. Words such as “open”, “choice”, “interoperability”, “standard”, “innovation” and “freedom” have been bandied about like patriotic slogans, but with meanings that are often distorted from their normal uses.
The aggrieved word I want to examine today is “compatibility”. Let’s see how it is being used, with some illustrative examples, the ipsissima verba, Microsoft’s own words:
From an open letter “Interoperability, Choice and Open XML” by Jean Paoli and Tom Robertson:
The specification enables implementation of the standard on multiple operating systems and in heterogeneous environments, and it provides backward compatibility with billions of existing documents.
From another open letter, Chris Capossela’s “A Foundation for the New World of Documents”:
… all the features and functions of Office can be represented in XML and all your older Office documents can be moved from their binary formats into XML with 100 percent compatibility. We see our investment in XML support as the best way for us to meet customers’ interoperability needs while at the same time being compatible with the billions of documents that customers create every year.
From Doug Mahugh: “The new Open XML file formats offer true compatibility with all of the billions of Office documents that already exist.”
And from Craig Kitterman: “Is backward compatibility for documents important to you? How about choice?”
Those are just a handful of examples. Feel free to leave a comment suggesting additional ones.
Compatibility. Better yet, True Compatibility. What is that? And what do you think the average user, or even the average CTO, thinks, when hearing these claims from Microsoft about 100% compatibility?
Let’s explore some scenarios and try to reverse-engineer Microsoft’s meaning of “True compatibility”.
Suppose you get a new, more powerful PC with more memory and upgraded graphics card and you upgrade to Vista and Office 2007. You create a new presentation in PowerPoint 2007 and save it in the new OOXML format. What can you do with it?
Can you exchange it with someone using Office on the Mac? Sorry, no. OOXML is not supported there. They will not be able to read your document.
Is this 100% compatibility?
What about Windows Mobile? Can I read my document there? Sorry, OOXML is not supported there either.
Is this 100% compatibility?
What about sending the file to your friends using SmartSuite, WordPerfect Office or OpenOffice, or KOffice? They all are able to read the legacy Microsoft formats, so surely a new format that is 100% compatible with the legacy formats should work here as well? Sorry, you are out of luck. None of these applications can read your OOXML presentation.
Is this 100% compatibility?
What about legacy versions of Microsoft Office? Can I simply send my OOXML file to a person using an old version of Office and have it load automatically? Sorry, older versions of Office do not understand OOXML. They must either upgrade to Office 2007 or download and install a convertor.
Is this 100% compatibility?
I have Microsoft Access XP and an application built on it that imports data ranges from Excel files and imports them into data tables. Will it work with OOXML spreadsheets? Sorry, it will not. You need to upgrade to Access 2007 for this support.
Is this 100% compatibility?
What about other 3rd party applications that take Office files as input: statistical analysis, spreadsheet compilers, search engines, document viewers, etc. Will they work with OOXML files? No, until they update their software your OOXML documents will not work with software that expects the legacy binary formats.
Is this 100% compatibility?
Suppose I, as a software developer, takes the 6,039 page OOXML specification and write an application that can read and display OOXML perfectly. It will be hard work, but imagine I do it. Will I then be able to read the billions of legacy Office documents? Sorry, the answer is no. The ability to read and write OOXML does not give you the ability to read and write the legacy formats.
Is this 100% compatibility?
So, there it is. A don’t know if we’re any closer to finding out what “100% compatibility” means to Microsoft. But we certainly have found lot of things it doesn’t mean.
A quick analogy. Suppose I designed a new DVD format, and standardized it and said it was 100% compatible with the existing DVD standard. What would consumers think this means? Would they think that the DVD’s in the new format could play in legacy DVD players? Yes, I believe that would be the expectation based on the normal meaning of “100% compatible”.
But what if I created a new DVD Player and said it supported a new DVD format, but also that the Player was 100% compatible with the legacy format. What would consumers think then? Would they expect that the new DVD’s would play in older players? No, that is not implied. Would they expect that older DVD’s could be played in the new Player? Yes, that is implied.
This is the essence of Microsoft’s language game. The are confusing the format with the application. This is easy to do when your format is just a DNA sequence of your application. However, although Microsoft Office 2007, the application, may be able to read both OOXML and the legacy formats, the OOXML format itself is not compatible with any legacy application. None. The only way to get something to work with OOXML to write new code for it.
This is not what people expect when they hear these claims of OOXML being 100% compatible with legacy formats.
Doug Mahugh says
Humpty Dumpty quotes, I love it. Here’s another one I like:
“And if you take one from three hundred and sixty-five what remains?”
“Three hundred and sixty-four, of course.”
Humpty Dumpty looked doubtful, “I’d rather see that done on paper,” he said.
Here are some answers to your questions above:
Mac compatibility — coming soon.
Windows Mobile compatibility — coming soon.
SmartSuite, WordPerfect Office, OpenOffice, KOffice — Corel and Novell have announced plans to support Open XML, I’m not sure about the others.
Legacy versions of Office — yes you have to install the convertor (Compatibility Pack). It’s a one-click install, and it’s free.
Access XP — correct, you have to upgrade to the currently shipping version for Open XML support.
3rd-party applications — correct, they’ll need to add support for the Open XML formats. The Office File Converter (freely available with the recently released Office Migration Planning Manager) can be automated to provide that support, for those who don’t want to write code to support Open XML.
The Open XML spec doesn’t document Office’s binary formats — correct.
As for what we mean by “100% compatible,” here’s my personal opinion on that: we mean that Open XML can capture all of the functionality of the billions of existing Office documents and that those documents, once converted, will have predictable performance and behavior nearly identical to the original. You quoted me as saying 100% compatible last July, and I’ll admit that I’ve stopped saying 100% — I now tell people that backward compatibility is “nearly 100%” because although I’ve seen only full-fidelity conversions I’ve heard that there are a few rarely used things in the binary formats that may not convert perfectly into Open XML.
For example, take a complex Word or Excel document from the past, and convert it to ODF through one of the products you mentioned above. Now take the same document and convert it to Open XML through Microsoft Office. And then ask the user: which version looks more like your original? The answer is pretty consistent: the Open XML version. When we say that Open XML is “compatible with billions of existing documents,” that’s what we mean. And when users see their options, they usually agree that Open XML offers the best option for moving their existing documents forward to an XML-based standard.
Thanks, Doug. But none of that is really 100% compatibility with legacy anything. That is really just saying that OOXML is compatible with code that Microsoft is writing months after OOXML was standardized by Ecma. But the qualities of the format were set the day the standard was approved by Ecma. The standard does not gain capabilities by Microsoft writing code. Microsoft applications may gain capabilities, but the standard is what it is, and is as compatible as it is going to get the day it was standardized. If OOXML was really compatible with legacy binary formats then they would work without requiring code changes or customer upgrades.
I understand you on the intended model equivalence between OOXML and the legacy formats. Personally I think that it is quite a bit less than 100% when you consider what is missing from the OOXML standard (specification of scripts, macros, encryption, OLE, etc.). But at least I believe I understand your point here.
However, is model equivalence really what the average consumer thinks when Microsoft executives say in an open letter that OOXML “provides backward compatibility with billions of existing documents”? I don’t think so.
This (to me at least) is stretching the meaning of “compatibility” well beyond normal use. Compatibility implies an actual present substitutability, not some potentiality that it is possible for someone, somewhere, sometime to write a program that converts between the two.
Similarly, if I buy a DVD that claims to be 100% compatible with legacy DVD formats, I don’t expect later to find that I need to replace or upgrade my DVD player in order to watch the DVD.
Your comparison between MS Office exporting a complex Word file as OOXML and the same file exported by OpenOffice is made more vulnerable to criticism by the fact that neither OpenOffice.org nor KOffice nor AbiWord have access to a current version of the Word binary file format specification.
A more interesting test will be to load the same Word document into Novell’s OpenOffice and save to both ODF and OOXML format. That makes it a little more fair, since you are eliminating differences in the binary format parsing code. I wonder which output will look better? Anyone try this yet? Any guesses on the outcome?
doug mahugh says
I’m tempted to say the OpenOffice test you suggest is a bit biased because OpenOffice presumably knows a lot more about optimizing for ODf than Open XML, but that’s confirming your point: MS-Office knows more about the binary formats than anyone else.
What would really help frame this debate would be a simple word processor or spreadsheet that supports both ODF and OXML, with no legacy connection whatsoever: just start from scratch to build it, looking to the two specs, and implementing each new feature in both formats. I’ll bet we’d all learn quite a bit from that exercise. Hey, maybe IBM and Microsoft could co-sponsor an open source project — I’ll pitch it here if you pitch it there. :-)
With Doug’s definition of compatibility, it is pretty clear he talks about “read and convert” compatibility. This is the ability to read the document and retain the functionality and fidelity across conversion.
What is not included is the promise of “convert and write” compatibility. This is the ability to convert documents in the legacy format, say for compatibility with third party applications that can’t handle the new formats. The world is up for major conversion efforts here.
Doug’s solution to the missing compatibility features appears to be upgrade everything to support OOXML and then the problem goes away. I don’t see an option to refuse or delay the upgrade and still be able to receive the information.
I would be curious to find out who is better at convert and write from its native XML format to the binary legacy format? Is it Office 2007 or Open Office?
Well, “read and convert compatibility”, that really isn’t a property of the format, is it? It is a property of the MS Office application. The file format alone does not achieve anything. Maybe it is too subtle a point, especially for those who are viewing the formats up close. It is obvious to us. But to the person merely reading Microsoft’s claims that OOXML is “100% backwards compatible with billions of existing documents” this is quite deceiving.
The Wraith says
Where OOXML talks about compatibility (interpretation between different versions) I see ODF talk about interoperability (interpretation between same version). To be fully interoperable there should at least be two applications that can communicate arbirtrary ODF files.
However allthough a good number of documents can be easily exchanged full interoperabiltiy has not happened yet even 20 months after ODF has become an OASIS standard
Creating a goal for a standard does not mean the goal is nescesarily achieved by just creating the standard.
I think the backwards compatibility is important to current Office users. They want fidelity that their documents will still produce the same results when they use a new Office product. The backwards compatibility is not ment for opening up the binary formats in their binary state. There is a limited licensed program for obtaining the binary specs for that.
Well, to speak as the devil’s advocate for a minute, Microsoft is making a valid point using the wrong words.
I think what they’re saying is that OOXML’s features are a superset of the features of the .doc format. As such, a document saved as a .doc document, converted to an OOXML document, and then loaded back into the same program will render and behave identically to the original document. This is certainly a point in OOXML’s favor.
However, you are correct when you say that backwards compatibility is absolutely the wrong term for this. It sure sounds good, though, doesn’t it?
Nevertheless, this usage is not uncommon. I think it’s because many products claim to be “backwards compatible” with their previously versions. For instance, the Wii and the Playstation 2 both claimed to be backwards compatible with the Gamecube and the Playstation, respectively. The formats barely related to each other (heck, a Wii disc is twice the radius as a Gamecube disc), but the newer device worked for both the old and the new format. This has become an awfully common definition for backwards compatibility, and it’s presumably the one Microsoft’s using.
The work done here and at other places is amazing. Thank you very much. I can see a picture emerge from all the bits and pieces.
Words like “compatibility” and “interoperability” have a connotation of symmetry. But what is implemented by Microsoft is assymetric. This have deep impacts.
Compatibility is of the “read and convert” type. New OOXML documents can’t be “converted and written” into legacy formats without losing fidelity. This creates a pressure for everyone to upgrade to the new format. The more there are people and organizations that upgrade, the more the social pressure will force everybody else to upgrade as well.
Interoperability is good enough to enable third party producers of OOXML but not good enough for third party consumers of OOXML. This other assymetry is Bob Sutor’s concept of “intraoperability”.
Gary Edwards is right with his analysis of the triple play based on Exchange/Sharepoint. Take a good look at the functionality of Sharepoint 2007. They bundle the following functionality:
– Corporate Portal
– Content Management
– Document and Records Management
– Entreprise Workflow
– Business Intelligence
– Instant Messaging
– Wikis and blogs
This is quite a wide range of functionality. Vendors in these markets are pressured to upgrade their software and support OOXML due to the assymetry of compatibility. But they can only produce OOXML, not consume it because of the assymetry in interoperability. We know from the EU anti-trust proceeding how hard it is to get Microsoft release their specifications. Vendors will have to enter partnership with Microsoft to get the missing information and become consumers of OOXML. Otherwise they just won’t be competitive.
Any guess on whether these contracts will contain clauses restricting the support of alternative formats like ODF?
Vendors in the same markets as Sharepoint are between a rock and a hard place. If they don’t sign agreements with Microsoft, their applications can’t be consumers of OOXML. If they sign the agreement, they are unlikely to help the adoption of an alternative format that can free them from a Microsoft dependency. Eventually the contracts will expire and OOXML will evolve or be extended. Microsoft can pull their lifeline any time they want.
This is a good place for reading again the quotation from Aaron Contorer on Embrace and Extend that was posted in a previous article in this blog. It is happening under our very eyes. We are witnessing the birth of the anti-trust disputes of the next decade. Products in the same markets as Sharepoint 2007 are slated to go the way of WordPerfect, Lotus 1-2-3 and Netscape. We know the recipe, we have seen it before. The only difference it we know what is going on ahead of times instead of after the fact.
But no one says that Wii disk is “100% backwards compatible” with a Gamecube disk, do they? No. The claim is made in terms of application compatibility, not format compatibility.
That is the error and the deception in how Microsoft is describing OOXML. The fact remains that very little today is compatible with OOXML.
Wraith, Something to keep in mind when looking at ODF test results is the difference between open source projects and commercial vendors, and how they release software. You will not see a version of Office for the Mac with only partial OOXML support. The first time you will see it will be when it is fully working. But the “release early and often” philosophy of open source leads to there being many partial implementations of the ODF standard at any one point. One could just as well looked at the various early versions of the CleverAge Add-in to score points against OOXML, right? This is more to do with the different development models and release schedules than the standards.
But I still hold that there are lot of ways to look at what backwards compatibility means. It’s quickly becoming a fuzzy, weasel word. For example, I just took a look at the Wikipedia entry on backwards compatibility, which includes the line:
Data does nothing in the absence of an interpreter, so the notion of compatibility does not apply to document files, it only applies to software.
This sort of definition makes this entire argument moot. Come to think of it, that’s a really terrible clause in Wikipedia. It’s neither factually correct nor proper grammar. (Two independent clauses separated by a comma? Those barbarians!) Someone should really change that.
Anyhoo, my point is that Microsoft’s compatibility argument, at least to me, really seems to be about whether or not a .doc file can have its meaning converted accurately into one of the new formats. They seem to be arguing that an OOXML file would be able to more faithfully reproduce represent the contents than an ODF file. They got their words wrong, but that’s what I think they’re trying to say.
That definition is indefensible. For example, SACD’s are backwards compatible with older audio CD’s because they have two versions of the music, in two different streams, so they can play on older CD players.
Also for the last 10 years or so Microsoft Office formats have been backwards compatible with previous versions of Office. No doubt also that OOXML is designed so that future versions of Office will have file formats that are backwards-compatible with OOXML.
So the notion of a backwards compatible format is most certainly a well-founded one and is a recurring engineering pattern, with known best practices. You can’t pretend it doesn’t exist.
I’m as charitable as the next guy, but when Microsoft executives, in an open letter, not an off-the-cuff remark in an interview, but in a published letter that was no doubt reviewed by many before it was released, says that OOXML “provides backward compatibility with billions of existing documents”, and this remark is copied and parroted by others, then this not simply a case of “making a valid point using the wrong words”. It goes quite beyond that.
Please redefine 100% compatibility: We received our first OOXML document. We coudn’t read it in Office 2003.
Nice try: to all Office 2007 users: please save as .doc first :)
Novell has released its OOXML plug-in for Open Office. Brian Jones argues that “the war is over” and “the winner is both” because there are two vendor implementations of OOXML.
I wonder. does the Novell plug-in handle every OOXML that is thrown at it? Or do they miss something like the “optional” features designed to handle legacy documents from old applications? That might matter for purpose of meeting the regulatory requirement of multiple independent implementations from states like California. Do partial implementations count?
I saw that article and had a good chuckle. The last I checked ISO NB’s still had not had the opportunity to vote up or down on OOXML. So I’d hesitate to say that this is all over. You can rent the hall and buy the champagne, but I wouldn’t uncork the bottles until the votes are in.
Or maybe Brian is saying that it is victory regardless of OOXML’s status in ISO?
As for the Novell translator, I did take a quick look at it. Here’s something to try: Download the oxt extension, rename it to a zip. Then unzip it and extract the big odfconvertor.exe. Load that file into your favorite hex editor, or a good text editor or even run strings on it to get just the text. You’ll soon see around 20,000 lines of XSLT transforms with CleverAge copyrights.
There may have been additional conversion work from Novell, but certainly a large amount of this is simply taken from the CleverAge ODF Add-in for Word, repackaged and integrated into OpenOffice. The original CleverAge required C# and .NET. The Novell version uses Mono. Like the original, this translator is Word only.
So I would not hold this up as a shining example of an independent implementation of OOXML. Or certainly no more than I would call Novell’s version of OpenOffice an independent implementation of ODF.
Nothing wrong with that per se. It is better to have one good translation effort than a bunch of poor ones.
MICROSOFT HAS had a long, a very long history of litigation, court orders, patent infringements and antitrust lawsuits against it since the very beginning of its history. The surprising thing is not only the number of those lawsuits against Microsoft – at one time, it had more than 130 pending – but more importantly, the sheer amount of money it represents. Microsoft Corporation has been ordered to pay nearly $9 billion as of Thursday 14 July 2005.
Though Microsoft is keen to emphasize the fact that they are not guilty of any wrongdoing in many of the lawsuits, they would prefer to pay rather than anything else. This has lead some observers to speculate that fines has been a way to “oil” the progress of Microsoft.
Mythic Still in court?
New Mexico $3,150,000
North Carolina $89,000,000
Carlos Armando $8,960,000
North Dakota $9,000,000
Discrimation Suit Still in court?
DR DOS/Caldera $500,000,000
Employee fired $9,000,000
South Dakota $9,330,000
Forgent Still in court?
Go Still in court?
Perma Te $96,000,000
Wordperfect Still in court
E-data Still in court