The Standards Blog

More on PDF vs. Microsoft's "XML Paper Specification"

OpenDocument and OOXML


My blog entry from last Friday has sparked some commentary (a few examples are here, here, and here). One by Mary Foley particularly caught my eye, and moved me to respond to her. Here's the part of Mary's story that I thought merited a response: 

Andrew Updegrove, cofounder of Gesmer Updegrove LLP and editor of the ConsortiumInfo.Org blog — as well as one of the leading opponents to Microsoft’s Open XML standardization effort — issued a dire prediction: 

“If OOXML (Office Open XML), and now Microsoft XML Paper Specification, each sail through Ecma and are then adopted by ISO/IEC JTC1, then I think that we might as well declare ‘game over’ for open standards.”


I’ve been no fan of Microsoft’s methods for drumming up support for its standardization effort around Open XML. But I don’t see how the existence of multiple standards portends the end of open standards … even if a company that has abused its monopoly power is one of the players. Doesn’t “open standards” mean they should be open to the inclusion of technologies from anyone, even Microsoft?


Microsoft, like IBM, Sun and every other open-source and closed-source tech vendor needs to have its technologies designated as “open standards” in order to qualify for many requests for proposals, especially from government customers. That’s what’s behind Microsoft’s attempts to get standard status for Open XML and XPS.

I agree that there's nothing wrong with multiple contenders for "standardship," if you will. Mostly, though, it's a matter of timing. You might find this piece that I wrote last year interesting, where I try to distinguish between "standards competitions" and "standards wars:"   It's part of an entire issue of the Consortium Standards Bulletin dedicated to standards wars.


What I call competitions can help bring products to market faster while allowing the best technologies to succeed – and ultimately become the basis of widely popular standards. Wars, on the other hand, can have many casualties (often you and me), don't always result in the best technology becoming ubiquitous, and usually have only one winner.


Let's look at some examples of each. The early competition between wireless standards began head to head between contenders such as BlueTooth, WiFi, HomeRF and others that are now forgotten - plus other standards that would use already existing wiring to accomplish a similar, if more limited, goal. By starting many horses in what was originally seen as the same race, the deficient ones (e.g., HomeRF) failed, while the good ones won, each shifting into the niches where they worked best - WiFi for networks, BlueTooth for device to device, and so on.


In a standards war, the opposite happens - VHS and Betamax being the most notorious example, where everyone loses, except for the patent owners underlying the winning standard. The Blu-Ray/HD-DVD contest going on today is, of course, the current replay.


So which way should we view the current face off – as a war or a competition? To my mind, it's the former, because there's already an available standard and (Adobe's refusal to license to Microsoft on acceptable terms - or so we are told - aside), the only benefit to there being a second standard is to Microsoft, and this, to my mind, would further entrench it in the Office space, where it's dominance has stifled innovation for going on decades.


Note also that in this case, Microsoft doesn't have "billions of legacy documents" to protect, to provide cover for coming up what it calls a different standard (than ODF) for a different purpose (converting just Office documents, not creating competing products). In this case, Microsoft's new standard would be. . . just another standard to do a job that another is already doing, and doing well I may be wrong, but I'm not yet aware that the Microsoft standard would provide great new features. Instead, it would be just another Microsoft version of something that already exists, like a work processor, spreadsheet, GUI, browser, and so on. Do we sense a pattern here?


And, of course, Microsoft is also making a plugin available, so all of its customers are already taken care of. So again, the need for a second standard for anyone other than Microsoft is . . . what?


I don't have any problem whatsoever with Microsoft coming up with its own technology for saving documents in an equivalent format, or for it making that technology open to anyone under, for example, a covenant not to assert any Microsoft patents. What I don't see is the need for that format to achieve official standard status. Would you really want another size light socket besides the one you have, now that the old models are everywhere? 


The open question, of course, is whose fault was the breakdown with Adobe was, which provides the only real justification (to my mind) for Microsoft to be taking this action. We don't really know, as we don't know how many things were tied together and who asked for what. All we do know is what the two companies chose to tell us. 


We do know that Adobe later committed the rest of its technology to ISO. Again, though, we don't know if Microsoft then went back to knock on Adobe's door again.


Net net, I see two scenarios here. If Adobe played false to its pledge to license its PDF patents on "reasonable and non-discriminatory terms" (RAND), then perhaps Microsoft is somewhat justified in playing hardball. Perhaps the Ecma announcement is only the opening salvo of a new licensing negotiation between Microsoft and Adobe. But if it was Microsoft that was being unreasonable, or if Microsoft's Ecma submission is unrelated, then it seems like this submission has something in it for Microsoft, and no one else. If that's the case, then I will be truly disturbed to see any resulting Ecma standard follow OOXML down the road to ISO/IEC JTC1


For further blog entries on ODF and OOXML, click here


subscribe to the free Consortium Standards Bulletin



"So which way should we view the current face off – as a war or a competition? To my mind, it's the latter"

Did you mean "the former"?

In reply to by Anonymous


Oops - thanks very much.  I posted this without proofing due to some urgent news that just came out, and that I'll be posting very shortly.

  -  Admin

For the past two decades, Microsoft has been following their well-known "Embrace, Extend, Extinguish" strategy.

Using this strategy, Microsoft would repeatedly adopt an industry standard, add their own extensions to it, and thereby, either destroy the standard, or use the extensions to drive competitors out of the market.

Microsoft used this strategy to "pollute" Java, thus delaying the advance of e-commerce and other Internet services for the decade it took Microsoft to develop and offer an alternative.

Not that long ago, Microsoft's "Halloween" document restated this strategy as it applies to Open Source software:

> "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."

And, with OOXML, we see undocumented Microsoft extensions built in from the start.

Given this history, I have no doubt that Microsoft's long term goal was to take control of the PDF standard. I think it very likely that Microsoft was demanding the right to add proprietary extensions to PDF, and that Adobe wisely turned them down.

As to what those extensions might be, my first guess would be embedding proprietary Microsoft audio and video binary formats. I expect that we will see similar binary extensions in Microsoft's PDF alternative.

A poster on the previous topic caught my attention and sparked the following idea: It's becoming clear that MS is exploiting the layman's gullibility by intentionally conflating 'application' with 'document format'. This is due to similar-sounding names and the PR FUD that OOXML must be 'backwards-compatible' with 'legacy documents'. Fundamentally, the idea boils down to repeating all MS 'explanations' / 'arguments', replacing all occurances of 'OOXML' with 'MS BetaMax' (due to both being proprietary in nature and the way both limit(ed) the user's rights and competition through legal 'intellectual property' hurdles) and replacing all occurances of ODF with 'DVD'. Replace all occurances of 'office documents' with 'video movies' and all occurances of 'application' (if any) with '__________ player' where the player type is 'MS BetaMax' if MS Office is the application, specific brands of DVD players ('OO', 'Koffice', 'Google Office', etc) for ODF, or the generic 'video player' where the application under discussion is not clearly identified. "Legacy Documents" should be replaced with "8-track tapes". Should anyone question this substitution, point out that the different formats are direct correlations to document formats, that the 'video movies' can be translated from one format to another via various 'plugins' (literally !) and/or 'converters' and that the format specifications are each correctly represented as they are currently deployed in the real world (technically, MS has already abandoned the MS OOXML standard, but I'm assuming that they don't want that fact known too widely until AFTER OOXML is through the ISO.) That makes one vendor making 'MS BetaMax' players (that actually make something close enough to 'MS BetaMax' specifications to fool most people, but that does not properly play 'video movies' produced by competing 'BetaMax video players' (such as the 'Clever Age BetaMax recorder/player' or the 'openSuSe BetaMax recorder/player' that is essentially a re-branded 'Clever Age player/recorder' because the primary vendor (MS) has already deviated from its published format specification. It also clarifies that several vendors use the DVD format and that they all play each other's 'video movies' interchangably and this situation is intolerable to the maker of 'MS BetaMax' devices since this represents an emerging threat to their dominant market share in 'video content distribution' and severe loss of sales. Those vendors creating DVD players can add features at will and differentiate between each other based on feature sets. (I'll refrain here from pointing out the details of the similarities this association makes to the RIAA's anti-piracy lawsuits and legal threats 'justified' by loss of sales revenue "due to rampant illegal piracy".) As a test, try this substitution within this article and see what it does to the discussion points: OOXML => "MS BetaMax format" ODF => "DVD format" office documents => "video movies" OO => "OO DVD player" KOffice => "KOffice DVD player" Legacy Documents => "8-track tapes" "MS OOXML Plugin" => "DVD - to - MS BetaMax converter" Note: The "MS OOXML Plugin" device cannot work unles it first converts each DVD to BetaMax format before the video movies can be opened or viewed (just like the actual MS Conversion plugin !). The MS BetaMax -> DVD conversion might be implemented, but if so, that will require a seperate step that must be done AFTER the video movies are first saved/converted to MS BetaMax format.

OOXML cann be considered an alternative to ODF. Referring to OOXML as an open standard is deceitful to the extreme. OOXML has many references to proprietary Microsoft trade secrets and formats as requirements, which ensure that nobody except Microsoft or Microsoft licensees can fully implement it.
Microsoft's excuse for putting these into the OOXML specification is that they are necessary for backward compatibility with legacy Microsoft documents. This is also a blatent lie: ODF can do the same without mandating proprietary behaviours and formats in the specification, and can also achieve 100% backward compatibility by using the ODF foreign element tags. The OpenDocument Foundation's ACME 376 demonstration plug-in (a demo for their forthcoming Da Vinci plug-in for ODF v1.2 for MS Word) proves this.
The only reason for Microsoft specifying trade secrets and proprietary formats in the OOXML specification is to ensure proprietary lock-in to Microsoft applications and Microsoft licensed technologies. Microsoft's covenant not to sue explicitly excludes proprietary Microsoft formats, which means that only Microsoft or Microsoft licensees will be able to use them ith OOXML.