I thought of a friend's ex-husband when I learned this week that despite Microsoft's promises of a new openness and its assertions regarding interoperability for its OOXML (formerly known as OpenXML and also known as EOOXML) and despite having offered it as a *standard*, it seems that it's another case of promises, promises. From what I've been reading, which I'll share with you, I think it's time to ask ourselves some serious questions: does OOXML really qualify as a standard? Or is it yet another monopoly-enabler in the guise of a standard?
It's a good time to ask, because it turns out that we are right now in the window of time where contradictions in the OOXML standard can be reported by member bodies of the ISO/IEC Joint Technical Committee 1. February 5 is the deadline, so now is the time to bring such to their attention. Some have already found some contradictions, and perhaps you will know of more to add to the list. If so, put them in a comment here or on either of two new page we've set up on GrokDoc, EOOXML at JTC-1 and EOOXML Objections wiki pages, each a work in progress. You'll find abundant resources there for further study and consideration. Marbux has also written up an explanation of the ISO process, which I'll put at the very end.
The bottom line:
Because of the apparently unresolvable contradictions being discovered, the questions being asked are whether ISO should reject EOOXML from
the fast-track process and instead use the regular process, and whether, if there can be no resolution of some of the contradictions discovered, ISO should accept the specification at all. Is the "fast track" process even appropriate when there are such questions, and more, in the air? Is the Ecma process itself flawed, in that it allows, even mandates, conformance with a single vendor's file formats?
Let me explain what I mean by contradictions and I'll tell you about my friend's ex and how he fits in to all this.
The Novell-Microsoft Deal: Interoperability for Whom?
First, though, let me address the Novell-Microsoft deal, the part about interoperability. We've heard much talk about how it will lead to greater interoperability for everyone, specifically with OpenXML (or OOXML or whatever it's called this week). What's the matter with the naysayers? Don't we appreciate that Microsoft is finally opening up and embracing openness? This is good for us all in the community, I've read. I suppose they'll tell that to the EU Commission too. So that's the happy talk. But read this, Jeff Jaffe's Blog. Does it sound to you like Novell plans on sharing on an even playing field?
In my last posting, I defined Novell’s technical strategy as:
The world’s best and most interoperable Linux surrounded with management services that leverage our footprint to build a business solving customer problems in heterogeneous systems management.
If Novell is the "most interoperable" Linux, how does that work? Obviously, they don't plan to share. And in fact, Jaffe goes on to explain Novell's differentiation strategy, including this relevant slip:
And on the desktop side. XGL graphics. Wobbly windows. 3 dimensional windows. Search. Media players. Plug and play. Interoperability. Almost a never ending list.
So, they plan to be the only one in the Linux world that can actually interoperate with Microsoft. How do you think they will achieve that? By sharing? On the contrary, they already market themselves as uniquely interoperable, which means they get to interoperate and you don't, unless you are their paying customer. Competitors in the market need not apply:
Novell is the company which stands at the nexus of both of these key platforms. (In addition to bringing the NetWare base forward on SUSE Linux Enterprise Server as part of Open Enterprise Server.)
Why is that? Only Novell has Microsoft’s endorsement as its partner to drive Linux-Windows interoperability. So – of the Linux vendors - only we can speak authoritatively about Windows.
See? "Only Novell" can do this. That isn't interoperability, in the sense that you'd expect from a standard, is it? It's just another Microsoft partner, maintaining the Microsoft unwillingness to share technical information with real competitors, to my eyes. Why would you even need the interoperability work between Novell and Microsoft, if Microsoft planned to offer a standard the whole world could use equally? Isn't that what a standard is supposed to mean?
Now, about my friend's ex.
Did you ever have a friend or relative who married a philandering ladies man? I did. My friend married one years ago, and I still remember trying to warn her. Guys like that generally leave quite a wake as they put-put through life's waters, and I had learned about his ways from someone. So I naturally told my good friend.
If you've ever had a similar experience, you know exactly what happened. She told me I was wrong, she didn't believe it, and to mind my own business. And the parts that she couldn't deny because there was incontrovertible proof? He'd changed. He'd told her that it was all in the past. Now that he'd met her, he was a changed man. So they got married, she barely spoke to me for two years, after which she told me that everything I'd told her had proven true, and they were getting a divorce.
How do guys like that do it? How do they make good-hearted women believe that they will straighten up and fly right and get them to agree to marry them? Vanity? Inexperience? The blinding power of love? I have no idea, but I observed that creative and convincing half-truths and even lies play a role. If the wife finds lipstick on his collar, he'll tell her with urgent "sincerity" -- nay, tears in his eyes and an outraged tremor in his voice, indicating his pain that she'd even think of such a thing as infidelity -- that a co-worker had an epileptic fit in the cubicle next to his and he ran in to catch her just in time to keep her head from hitting the desk as she fell. He naturally had to hold on to her really hard, because she was thrashing about so much, and the lipstick probably got on his collar then. And if she's a dope, she'll believe him.
Now, I believe in the regenerative power of love as much as the next guy, but it has always seemed to me that you can predict a guy's future conduct by prior behavior in 99% of all cases. Men like Donald Trump or Magic Johnson are more honest about it, but to me that's not such a bargain either, considering what they might be bringing home. But ethically, it's certain preferable to just tell the woman up front, that you have no intention of being faithful. That way at least you don't destroy a trusting heart.
Now, when it comes to Microsoft, I think we can safely say that it too has left quite a wake behind it as it has conducted business. We learned yesterday that the plaintiffs in Comes v. Microsoft, the antitrust trial going on right now in Iowa, believe they have found in discovery evidence that Microsoft has failed to turn over APIs to competitors. Are you surprised? Microsoft was told to do that in 2002, in the Final Judgment. It's now 2007. Microsoft is still negotiating with the authorities overseeing compliance about when it really, really, really, no more excuses, has to come up with the documentation. If you read the incremental status reports, they are a positive hoot, particularly if you start with 2002 and read them all, one after another. Here's a fairly recent sample Status Report [PDF]:
Plaintiffs are surprised that Microsoft believes the rewrite project will take as long as
Yes, friends. Lots of happy talk of promises, but very little on the table. Not only did Microsoft get a two-year delay to do a rewrite, now it expresses it may not be able to meet the new deadline either. It seems documentation is very, very hard for Microsoft.
Here's a section from a 2003 status report [PDF]:
Plaintiffs are most concerned with Microsoft’s implementation of the requirement of Section III.E that it license certain Communications Protocols on reasonable and nondiscriminatory (“RAND”) terms. Plaintiffs note that Microsoft was required to do so in a timely manner, i.e., “[s]tarting three months after the entry of this Final Judgment . . . .” New York v. Microsoft Corp., 224 F. Supp. 2d 76, 173, 269 (D.D.C. 2002). Implementation of RAND terms is of particular concern to Plaintiffs because Section III.E was intended by the Court to be the “most forward-looking provision in the Court's remedy” and directed toward “unfettering the market and restoring competition.” Id. at 226; see also United States v. Microsoft, 231 F. Supp. 2d at 191-92 (recognizing that Section III.E is prospective and “particularly warranted in this case given the rapid pace of change in the software industry[;]” and stating that without it and other prospective provisions “it is quite possible that the core of the decree would prove prematurely obsolete”). As noted above, at Plaintiffs’ urging, Microsoft has made, and has stated that it will continue to make, changes to the MCPP terms. While Plaintiffs are continuing to work with Microsoft to improve the MCPP so that the Communications Protocols are licensed under RAND terms, Plaintiffs recognize that further steps may need to be taken, either pursuant to agreement or order of the Court, to account for Microsoft's delayed implementation.
It's now 2007. How are they doing with that delayed implementation? Read this piece of work [PDF], the "Supplemental Status Report on Microsoft’s Compliance with the Final Judgments", dated September 2006. Microsoft still is making qualified promises to deliver, all these years later:
As Microsoft has indicated to the TC, the schedule described above is aggressive and represents a commitment by Microsoft to delivering rewritten documentation of the highest quality as soon as practicable....
While Microsoft is fully committed to achieving the milestones set forth in the above schedule, it also recognizes that changes to this aggressive schedule remain possible (both over the next month as the schedule is being finalized and as the project continues) in order to incorporate additional feedback from the TC and to account for other unforeseen obstacles. Accordingly, Microsoft will stay in regular contact with the TC and the Plaintiffs regarding the need for adjustments in the schedule and will update the Court with respect to any changes.
Who are they kidding, aside from the monitoring folks, that is? Not me. To me, it's like lipstick on the collar. Again. I get the distinct impression, looking beyond what Microsoft says and concentrating on what it does, that Microsoft has no intention of sharing APIs to the extent it can help it or postpone it.
The EU Commission has been telling Microsoft to do the same thing, share APIs, even fining the company for not complying. The EU decision gave Microsoft 120 days to turn over APIs:
"Microsoft abused its market power by deliberately restricting interoperability between Windows PCs and non-Microsoft work group servers, and by tying its Windows Media Player (WMP), a product where it faced competition, with its ubiquitous Windows operating system. . . .
That was March of 2004. Do they have them? Microsoft's response at the time, from attorney Brad Smith, as reported by Reuters:
"Microsoft General Counsel Brad Smith said on Wednesday the European Commission's decision amounted to a 'compulsory licence' of the firm's intellectual property rights within Europe. 'We believe that will infringe our IP rights in Europe and it also violates the international treaty obligations pursuant to its (the EU's) membership of the WTO (World Trade Organisation),' he told a conference call."
And read Microsoft's objections to the EU Commission's complaint that documentation Microsoft turned over was useless. Microsoft is "fully committed to compliance", it wrote. But once again, it was somehow unable to turn over documentation that was useful. Here's what I wrote about the objections:
Reading the Microsoft reply to the criticisms of its documentation makes it obvious what the Trustee, Neil Barrett, was talking about. It seems that there was no way to follow the documentation without reading other books and white papers, not written by Microsoft, and looking up standards protocols elsewhere, etc. and trying to figure it out yourself. On page 2 of Annex 5, for example, you find out that the documentation refers to "existing engineering art" meaning books like "Active Directory Cookbook" and "Building LDAP-Enabled Applications". Using those books and white papers, the engineer, they say, can "scope his solution." From the "art" the engineer then makes a list of protocols his design will need to implement. Then he compares that list to the list of protocols Microsoft is offering to license, to find out if he needs documentation from Microsoft or can just implement from existing art entirely, etc. This is all perfectly normal, to hear Microsoft's apologists tell it, in documentation of this type. Honestly, it's a sketch. I'm not an expert, of course, but it left me rolling my eyes. That could just be because there's a little water under that bridge. But I came away with the distinct impression that Microsoft would prefer not to reveal anything it doesn't have to. Their view is that competent engineers are assumed to have a foundation of knowledge of Microsoft ways or the ability to bone up on the subject.
Well, that didn't fly with the EU Commission, and the dance continues. In that setting too, we've seen delay.
Now, Microsoft claims it has seen the light and changed its ways. OpenXML is the way forward. Microsoft is promising that its OOXML is open, an open standard. Yes, sirree, what could be better than openness and interoperability? And you believe them? Based on what? I feel like I'm talking to my friend again, trying to talk her out of marrying a man who wasn't being truthful with her (Cf. this article on some water under the interoperability bridge).
Contradictions Found Already
You may have seen Andy Updegrove's article on contradictions in Microsoft's OOXML, which I put in News Picks. Here are some contradictions he reported:
OOXML does not conform to ISO 8601:2004 "Representation of Dates and Times." Instead, OOXML section 220.127.116.11, "Date Representation," on page 3305, requires that implementations replicate a Microsoft bug that dictates that 1900 is a leap year, which in fact it isn't. Similarly, in order to comply with OOXML, your product would be required to use the WEEKDAY() spreadsheet function, and therefore assign incorrect dates to some days of the week, and also miscalculate the number of days between certain dates.
- OOXML does not follow ISO 639 "Codes for the Representation of Names and Languages."
- Similarly, 18.104.22.168 "Embedded Object Alternate Image Requests Types (page 5679) and section 22.214.171.124 "Clipboard Format Types" (page 5738) refer back to Windows Metafiles or Enhanced Metafiles – each of which are proprietary formats that have hard-coded dependencies on the Windows operating system itself.
- OOXML also apparently violates section 2.14 of the ISO/IEC Directives, Part 1, in that not all of what it takes to implement OOXML appears to be covered by Microsoft's patent pledge, in two respects. First, the pledge does not explicitly cover material that is referenced, but not included in the specification, and second, the Microsoft patent commitment does not cover optional features. Sections of OOXML that are not fully described include those that require compliant implementations to mimic the behavior of Microsoft products, such as those products and capabilities referred to above (OLE, etc.) Microsoft will need to clarify whether its patent commitment will in fact extend to these requirements.
If you wish to help find more, some keywords Marbux suggested to me are:
bitmask, Windows, application-defined, legacy, binary, blob, base64,
signature, encrypt, MSDN, Word, Excel,PowerPoint, Internet Explorer,
SQL Server, SharePoint, might, compatible, undefined, OLE, DDE, COM,
ActiveX, outside the scope, internal, SDK, .NET, device
In addition, you can search for the the text of the "guidance" quoted
by Ben Langhinrichs.
And here's Marbux's explanation of the ISO process, some legal issues regarding standards, why contradictions matter, the significance of the February 5th deadline, and some more examples of contradictions, all from his point of view:
Why Fast-Tracking OOXML is a Mistake
~ by Marbux
February 5, 2007 is a critical deadline for the future of office productivity software. That is the date by which national standards bodies must submit any objections to fast-track processing of the Microsoft Office Open XML specification by the ISO/IEC international standards body.
Only qualified "P" member bodies of the ISO/IEC Joint Technical Committee 1 ("JTC-1") have legal standing to submit such objections. Fast-track processing is the default JTC-1 status for the proposed Ecma-376 standard, more informally known as the Ecma Office Open XML ("EOOXML") standard. The default fast-tracking status can only be changed if a JTC-1 member national standards body submits objections, forcing a vote. Furthermore, there are far fewer opportunities for EOOXML's revision or to block its adoption by ISO/IEC unless EOOXML is successfully derailed from the JTC-1 fast-track procedures. 1
Despite the fact that no full-featured reference application is yet available for testing and review purposes and despite compelling evidence of EOOXML's unusually over-hasty preparation, the 6,039-page specification was submitted to JTC-1 for fast-track processing on January 5, 2007, providing national standards bodies a single month for detailed review and testing of the specification, and for filing of potential objections.
Can national bodies competently test and evaluate the EOOXML specification by February 5 or will one or more of them file objections to EOOXML fast-track processing? A few representative examples will provide a hint of the technical scope of the problem JTC-1 member bodies are facing.
File formats with no specification
The EOOXML specification (page 10) 2 states the ostensible goal of the proposed EOOXML ISO standard:
"The goal is to enable the implementation of the Office Open XML formats by the widest set of tools and platforms, fostering interoperability across office productivity applications and line-of-business systems, as well as to support and strengthen document archival and preservation, all in a way that is fully compatible with the large existing investments in Microsoft Office documents.
Indeed, the need for "compatibility" with legacy Microsoft Office file formats is the only justification Ecma offers for a proposed standard that duplicates and overlaps functionality with ISO/IEC 26300, the OpenDocument standard. That duplication and overlap is sufficient in and of itself to raise cognizable grounds for national bodies to object. Agreement on Technical Barriers to Trade, Annex 3 section H (members "shall make every effort to avoid duplication of, or overlap with … the work of relevant international or regional standardizing bodies"); see also ISO primary goal [PDF] of "one standard, one test, and one conformity assessment procedure accepted everywhere.”
However, the specifications for those legacy Microsoft file formats — the sole justification offered for duplicating the functionality of the OpenDocument standard — appear nowhere in the EOOXML specification and are unavailable to other developers. 3 Yet those formats' implementation is mandatory for conformance with the specification. How then, are national bodies to verify whether a duplicative standard is in fact necessary and can be implemented by all vendors? Apparently all of the claimed carefully-engineered compatibility with billions of legacy Microsoft files is reserved for the exclusive use of a single software vendor, Microsoft.
JTC-1's role includes ensuring that such vendor favoritism does not creep into the preparation of international open standards. Agreement on Technical Barriers to Trade, supra, section 2.2 ("[m]embers shall ensure that technical regulations are not prepared, adopted or applied with a view to or with the effect of creating unnecessary obstacles to international trade"); ISO/IEC JTC-1 Directives, section 11.1.2 (members may appeal JTC-1 action or inaction that is "[n]ot in the best interests of international trade and commerce"). A single vendor's development requirements do not necessarily create a market requirement for a duplicative standard, particularly when a proposed standard would have "the effect of" granting a single vendor a monopoly in the full-fidelity conversion of billions of legacy files to and from the supposedly open EOOXML.
The unavailability of the specifications for virtually all of the the legacy file formats also clashes irreconcilably with the verifiability requirements of section A.4 of Annex A to IEC Directives, Rules for the structure and drafting of International Standards, Part 2, ("[w]hatever the aims of a product standard, only such requirements shall be included as can be verified"). If compatibility with and implementations of the specifications for those legacy formats are mandatory for conformance with the proposed standard, disclosure of the specifications for the legacy file formats is necessary even to consider whether EOOXML achieves Ecma's stated goal of compatibility with those formats.
Vendor-specific application dependencies
The EOOXML specification is inappropriately replete with dependencies on a single vendor's software. As an example, "autoSpaceLikeWord95" (page 2161) merely defines
semantics in reference to a legacy application whose specific behavior
is nowhere specified. Instead, vendors are repeatedly urged to study the referenced applications to determine appropriate behavior. But no relevant specification is available for other developers to use and Microsoft's Open Specification Promise grants no right to decompile and reverse engineer the company's legacy applications. Such vendor-specific application dependencies create rather than remove "unnecessary obstacles to international trade" within the meaning of the Agreement on Technical Barriers to Trade, section 2.2, supra, inappropriately bestowing an enormous competitive advantage for a single vendor and rendering EOOXML ineligible for the status of an international open standard within the meaning of the relevant treaties.
Still other such application-specific tags and citations to the page numbers where they can be found were collected by Ben Langhinrichs along with the mentioned Ecma "guidance" for other developers to study the behavior of the host of legacy applications to implement the tags:
I was reading through the Office Open XML draft yesterday, and came across a whole host of scary elements. These are all from Part 4 of the draft specs, entitled Markup Language Reference, and, yes, those are the real page numbers. It is not a short documemt, and this may partly explain why. For example:
* autoSpaceLikeWord95 (Emulate Word 95 Full Width Character Spacing) - pages 1378-1379
* footnoteLayoutLikeWW8 (Emulate Word 6.x/95/97 Footnote Placement) - pages 1416-1417
* lineWrapLikeWord6 (Emulate Word 6.0 Line Wrapping for East Asian Text) - pages 1426-1427
* mwSmallCaps (Emulate Word 5.x for Macintosh Small Caps Formatting) - pages 1427-1429
* shapeLayoutLikeWW8 (Emulate Word 97 Text Wrapping Around Floating Objects) - pages 1442-1443
* suppressTopSpacingWP (Emulate WordPerfect 5.x Line Spacing) - pages 1462-1464
* truncateFontHeightsLikeWP6 (Emulate WordPerfect 6.x Font Height Calculation) - pages 1467-1468
* useWord2002TableStyleRules (Emulate Word 2002 Table Style Rules) - pages 1481-1482
* useWord97LineBreakRules (Emulate Word 97 East Asian Line Breaking) - pages 1482-1483
* wpJustification (Emulate WordPerfect 6.x Paragraph Justification) - pages 1483-1485
There are many more which relate to various parameters which are deprecated...
Now, on the one hand, Microsoft is to be praised for its careful presevation of attributes, features and behaviors which exist not only in its own earlier versions but also in those of competitive products. Good show! On the other hand, these do not belong in an open standard! This is a very clear case of vendor specific implementation leaking through into what Microsoft claims to be an open standard....
I have no objection to the goal of fully supporting legacy MS Office documents. I fully respect that as a goal for Microsoft. It just doesn't make it an open standard, it makes it a speciofication for MS Office....
To repeat, as I have said here and elsewhere, when MS introduced this as a full specification of the MS XML storage, they did a good thing. But that good thing does not then cancel out the bad idea of declaring this an "open standard". It isn't, and no matter how many times you defend their support of legacy documents, it won't change that. I also defend their support of legacy documents, and support their full specification of it, but not in a public standard.
There are many more that can be
quickly identified by performing a document search of the
specification for the text of the "guidance."
The barriers to implementation for other developers posed by such tags have been discussed by Robert Weir in some depth:
It is quite possible to write a standard that allows only a single implementation. By focusing entirely on the capabilities of a single application and documenting it in infuriatingly useless detail, you can easily create a “Standard of One”.
Here are some other examples of where the OOXML “Standard” has bloated its specification with features that no one but Microsoft will be able to interpret:
126.96.36.199 autoSpaceLikeWord95 (Emulate Word 95 Full-Width Character Spacing)
This element specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 95) when determining the spacing between full-width East Asian characters in a document's content.
[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]
...What should we make of that? Not only must an interoperable OOXML application support Word 12's style of spacing, but it must also support a different way of doing it in Word 95. And by the way, Microsoft is not going to tell you how it was done in Word 95, even though they are the only ones in a position to do so.
Bob Sutor has discussed the harm to be inflicted by the cumulative mass of vendor-specific application dependencies in EOOXML:
Who will implement Open XML correctly and fully? Maybe Microsoft. Why? Since it is essentially a dump into XML of all the data needed for all the functionality of their Office products and since those products are proprietary, only they will understand any nuances that go beyond the spec....
Fully and correctly implementing Open XML will require the cloning of a large portion of Microsoft’s product. Best of luck doing that, especially since they have over a decade head start. Also, since they have avoided using industry standards like SVG and MathML, you’ll have to reimplement Microsoft’s flavor of many things. You had better start now. So therefore I conclude that while Microsoft may end up supporting most of Open XML (and we’ll have to see the final products to see how much and how correctly), other products will likely only end up supporting a subset....
This means that data in Open XML form will be largely sucked into the Microsoft ecosystem but very little will escape for full and practical use elsewhere.
In my opinion, suggesting “choice” among ODF and Open XML by governments who are seeking control, true choice, and interoperability is nothing more than maintaining the status quo — a requirement for Microsoft products under the guise of supporting a “standard.”
All standards are not the same and providing support for all standards is not the same.
In a later article Sutor has offered a layman-level explanation with graphical depictions of the involved market forces:
When a single vendor or software provider makes it easier to connect primarily to his or her software, this is more properly called intraoperability.
In the intraoperability situation, one product is somehow central and dominant, either by marketshare, attitude, or acquiescence. The connectivity is supported by protocols and data formats that favor the central software, and those are often prescribed by the provider. The goal is to suck all important data and processing into the central software ecosystem, and it is in this sense that we use the prefix “intra.” ...
You may need special licensing to use the protocols or formats, and the central vendor may even try to standardize the specifications with weird rules stating that you can’t break compatibility with their products. The licensing might even prevent the use of the formats, protocols, or even a user interface by competitors or creators of open source software.
Just how thoroughly the EOOXML specification is dependent on a single vendor's applications 4 is well illustrated by the spreadsheet specification's "Date and Times" requirement (pages 3305-6). That section requires that spreadsheet dates treat the year 1900 as a leap year, which contradicts the Gregorian Calendar. This raises severe interoperability issues when interfacing with the many other developers' office suites, other office software, and development libraries that do properly implement the Gregorian Calendar. The specification straightforwardly acknowledges that this behavior is required for "legacy reasons." Indeed, it is a known bug work-around in the Microsoft Excel spreadsheet program, which would be imposed on other developers and software users by the EOOXML specification's adoption as an ISO standard, a problem discussed in more depth by Rob Weir:
By mandating the perpetuation of this bug, we're asking for trouble. Date libraries in modern programming languages like C, C++, Java, Python, Ruby will all calculate dates correctly according to the Gregorian Calendar. So any interpretation of dates in OOXML files in these languages will be off by one day unless the author of the software adds their own workaround to their code to account for Excel's bug. Certainly some will make the “correction” properly, at their own expense. But many will not, perhaps because they did not see it deep within the 6,000 page specification.
The EOOXML specification also creates barriers to interoperability where such barriers seem gratuitous. For example, the "Workbook Protection" section (page 2698) defines an encryption algorithm by including several pages of C-language source code that appears to have byte-ordering dependencies that will produce different results on different machine architectures. Likewise, the "Clipboard Data" section (page 5905) defines a schema type that can encode clipboard format values for Windows and the Macintosh, but appears not to allow for use by other operating systems. Yet another is "Conditional Formatting Bitmask" (page 2478), which mandates the use of bitmasks. Some of the standard XML processing tools like XSLT lack bitwise operators, making the use of such data impossible when converting to other XML formats.
For a multitude of reasons such as those summarized above, one must question Ecma's undisclosed reasons for selectively including a mass of required behaviors of implementing applications for "legacy reasons" whilst simultaneously disclaiming any responsibility to specify critical application functionality needed by other developers to fully implement the specification (page 13):
Existing files and applications exercise a broad range of formats and functionality that, if required by the conformance definition, would add an impractical amount of bulk to This Standard and could inadvertently obligate new applications to implement a prohibitive amount of functionality. This issue is caused by the breadth of currently available functionality and is compounded by the existence of legacy formats.
That is a somewhat less-than-compelling argument for withholding specifications required to be implemented by the repeated usage of the mandatory "shall" and "shall not" that appears throughout the specification. Annex H to ISO Directives, Part 2, supra (e.g., "shall" to be used only “to indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted” ); see also extended analysis by Robert Weir ("The OOXML specification, at 6,000+ pages has now just sucked in the complexity of one or more versions of HTML, MHTML, RTF and WordProcessingML. It requires that a conformant application understand these formats, but forbids a conformant application from producing them."); Microsoft Open Specification Promise (patent rights granted extend only to "required portions of the Covered Specification that are described in detail and not merely referenced in such Specification").
EOOXML was crippled from the very beginning of the Ecma standardization process by an inappropriate charter requiring compatibility with only a single vendor's file formats:
The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the [Microsoft] Office Open XML Formats.
That charter language forbade any deviation from a single vendor's specifications in development of the EOOXML "open" standard. Not surprisingly, most major software houses boycotted the pre-rigged work program and Ecma included in EOOXML no specifications for the interoperability of other vendors' applications that are based on the existing ISO OpenDocument standard. Furthermore, Microsoft's Chief Executive Officer has publicly stated that Microsoft Office — and by implication EOOXML — will only "achieve the level of interoperability [with OpenDocument] that customers can work with." That ignores, of course, the market requirement of full fidelity interoperability in automated business processes. There were no full-featured reference applications available for EOOXML testing and evaluation purposes by national bodies at the time of EOOXML's submission to JTC-1 that I am aware of.
In contrast, ISO/IEC's highly-interoperable OpenDocument standard has been widely implemented across the software industry and has been extensively put into service around the world. See e.g., this page that tracks government adoption of OpenDocument worldwide, current as of May of 2006. EOOXML has no comparable track record of support and adoption.
ISO/IEC's reputation is on the line in its processing of the EOOXML proposal. See ISO/IEC JTC-1 Directives, supra sections 11.1.2 and .3 (any JTC-1 member may appeal if a draft standard "may be detrimental to the reputation of IEC or ISO"). The 6,039-page EOOXML specification warrants close scrutiny that cannot feasibly be achieved within the time frames mandated by ISO fast-track standardization procedures.
My understanding is that governments' software procurement tenders are required to specify the existing OpenDocument standard absent exceptional circumstances, pursuant to the international Agreement on Government Procurement Article VI section 2 (technical specifications shall "be based on international standards, where such exist"). If that understanding is correct, Microsoft must support OpenDocument or give up the pretense that its "standard" is anything but its own private international standard.
There is an overview of relevant law and procedures here.
Because the specification is not consistently paginated throughout, all references are to the PDF file page numbers.
Microsoft's failure to disclose the specifications for its legacy office file formats came under antitrust investigation in Europe. The relevant specifications are not available to other software developers.
See also e.g., "Disable Features Not Supported by Target Browser" section (page 2120), detailing requirements designed to optimize output for various versions of Microsoft Internet Explorer and disregarding entirely MSIE's main competing product, Mozilla Firefox, as well as many other alternative browsers.