In case you want to see what all the fuss was about personally, the national body comments from the Microsoft Office product spec OOXML contradiction period are now online. If anything, they illustrate what a long, long way it has to go before becoming an ISO standard, if it ever does so. Also included is the Kenyan Appendix N objection plus the ECMA response. Share and discuss.
I still find it funny that the OOXML supporters (plural?) early on tried to say that the comments were all going to be nice and congratulatory.
Also See: An “OOXML is a bad idea” blog entry compendium
ISO did itself disfavor by fast-tracking Ecma 376, especially after as Kenya notes that the Ecma TC pushed through an unprecedented MS-OOXML 18 pages a day, rather than the usual 1 page per day for proper, thorough review.
Two things: (1) Microsoft folks should not gripe when it is rejected; and (2) if by Jove it is somehow approved, look for future plugin writers to be saying ‘how did this get in here?’ followed by gnashing of teeth (e.g., see Malaysia’s comments).
The biggest contradictions are in the response itself…
“OpenXML has been designed to be capable of faithfully representing the majority of existing office documents in form and functionality.”
vs.
“The consuming application has the ability to choose to also use that same behavior or to instead choose to ignore it.”
and..
“There were a small subset of settings that specified layout behaviors that shouldn’t be fully documented in the specification..”
We are special because it’s all about about being accurate to the original documents, except if you don’t want to, and you won’t, because we aren’t going to tell you what the original documents actually looked like.
My favourite is still:
OpenXML does not use hash functions for security purposes. Instead, they are used as an obfuscation mechanism for preventing passwords from being reverse engineered based on the hash.
Err… The sky doesn’t not appear blue, instead you are seeing mostly the shorter wavelengths of visible light, ie the blue ones.
I watched the whole Massachussetts, Ecma, and contradictions carnival. I feel that I have become very cynical. Maybe too cynical. I think MS will force or bribe their standard through ISO. And every governement is hedging against it.
My impression of the history was that MS became desperate after ODF got into ISO, and recruited Ecma and maybe some Ansi officials to get MSOOXML through ISO at ANY cost. Remember all the strange twists and turns, eg, the sudden repagination of the specifications a few days before the deadline and the unexpected fast-track by a USA official at the ISO/TC secretary.
Bob Hilf admitted in his own words that MSOOXML is inseparable from MS Office 2007 (see the Open Malaysia blog). My conclusion from this is that the specifications cannot be altered without big troubles for Office2007. A harmonization of the internal contradictions might require a complete rewrite of large parts of the Office suit as the XML exactly mirrors the internal memory layout of the program. So the response of Ecma seems to come down to: nothing will change.
I now seem to see pure MS desparation at work with a UK astroturf campaign. I read about all kinds of anti-ODF initiatives in, eg, recently in Maleisia and Florida.
Moreover, I heard many (all?) National Bodies are flooded with MS employees. So at the end, MS employees might be in the majority overall. But that seems still not be enough to “win”.
In the end, I expect MS to be able to force MSOOXML through ISO (with $50B in the bank everything is possible). At least all the governement bodies considering ODF seem to fear so too, and have written “community standard stewardship” into the requirements. Something that I interpret as targeted against MSOOXML.
Am I really to cynical?
Winter
Winter,
I think you are so cynical because you’ve learned that it’s safer.
Myself, I think that MSOOXML won’t make it through ISO. Yes, Microsoft is pushing hard to get it through, but I’m sitting on a Standards Technical Panel myself at present, and it’s not simple for one company to try and influence everyone at once.
Wayne
I was cynical and somewhat fearful that it might even get fast-tracked.
Having read my own country’s (UK) contradictions, I have to say that not only am I heartened by the contradiction responses, but I also feel that this is never going to be a standard now.
Not as is, anyway. Microsoft might try for a “version 2″, but the major re-write of Excel and Word that they’d need to do to support it will be painful for them. And then they still might stumble at the fact that by then ODF will be a revised, entrenched standard – and the ISO won’t want to have two Office Document Format standards.
I actually think that the most important message that needs to be gotten out from this is simply “Don’t write for MSOOXML”.
Because if you do, you’ll likely end up having to re-write your code for any future version that does address the contradictions – and given their nature, it won’t be a simple re-write.
ODF is already a standard, is stable, is being incrementally improved, and has a clear direction of travel.
MSOOXML is none of those things, and is heading towards either never being an ISO standard (and therefore never being selected by many governments and public bodies) or requiring major re-writes to become a standard.
Microsoft may be trying astroturfing, but I’d like to hear them explain to their customers just why any future ISO version of MSOOXML will be so different, and why it will require so much work to re-write applications for it.
Microsoft’s traditional strength is getting developer support behind their products, so that the solutions in the marketplace make their standards the de-facto ones.
Get the developers and the customers educated – that MSOOXML will cost them time and money – and Microsoft’s strength is turned against them.
Part of the issues with OOXML is that it’s just a rehash of the legacy stuff, surrounded by angle brackets. But instantiating actual Office 2007 documents cannot be done with the public OOXML alone. In other words, OOXML is only a piece of what should made public (I am playing devil’s advocate since even a quick reading of the specs show extremely poor design, such as using no less than 6 different and compatible ways to describe text formatting. Based on merit, Microsoft should be ashamed of themselves to put this crap in public) :
- to instantiate documents with VBA macros, you need the VBA run-time. The VBA run-time is not part of the specs, neither part of Microsoft’s covenant not to sue. When you know that, how do you instantiate Office 2007 documents without using MS Office ?
- to bind XML sources and OOXML elements, a proprietary technique known as “content control” is used. Problem : to instantiate content control requires a running instance of MS Word 2007/Excel 2007/Powerpoint 2007.
- the 6,000 page specs describe a fraction of the tags used, but not the actual semantics. Adding 15 years of legacy and really explaining how it works (for rendering purpose for instance) is more like 600,000 pages.
- OOXML is just a part of Microsoft strategy. XML is used to please the technical inept. Starting with Office 12, and it is now publicly reported that Office 14 pushes the strategy much beyond, Microsoft is pursuing an integration suite strategy in which server components such as their own MS Sharepoint are part of the equation. You read it right : you will soon be unable to work with MS Office documents if you don’t also use MS Sharepoint. Problem : the protocols by which Word/Excel/Powerpoint talk with Sharepoint are not documented, probably never will (Samba, anyone?). And the MS Office team was ordered by Bill Gates to remove any support for open protocols such as WebDAV to do this kind of communication (http://antitrust.slated.org/www.iowaconsumercase.org/011607/2000/PX02991.pdf).
Let me spell it out differently. There cannot be a non-Microsoft product that supports Office 2007 documents accurately. Is it wise to allow a single vendor to restrict the freedom of choice of everyone? Is it wise to invest in a proprietary technology that is changing so fast that you are sure to be left in the dust in a few years if you stop buying Microsoft software over and over again?
Oh, last but not least, the “backwards compatible” claim is also a lie. An example of that is their new chart drawing engine which both 1) does not render well existing charts 2) is full of run-time bugs.
I have it on good authority – my own nation New Zealand’s JTC representative/s – that they opposed the “Fast Track”ing of ECMA 376 because there was already an adequate standard – OSO/IEC 26300 aka ODF – in place.
That’s not unassailable, being merely procedural, but it’s difficult to get around, particularly as there are already an adequate number of applications supporting ODF.
What should be also raised is that ECMA 376 is based on and is intended to be feature-for-feature compatible with MS Office 2k7. Which means that Microsoft are in a cleft stick of their own making. If they take on board the substantive objections such as Kenya’s, and ignore the procedural objections such as New Zealand’s, and change ECMA 376 to bring it into line with expectations, it will no longer be representative of MS Office 2k7, and thus will be in breach of their obligations under the ECMA 376 charter. If they don’t make the effort, more people will follow Kenya’s lead and throw it out the window. And every effort they make to bring MS Office 2k7 into line with a revised ECMA 376 will slow down any further development of any successor to MS Office 2k7, and will be worse than a FUD launched at Microsoft from the Lotus/IBM firing range. Own goals are never popular.
Microsoft really can’t win this, play it as they might.
Maybe they should all sit down and read “Joel on Software” and “The Mythical Man-Month” – but Microsoft’s reputation for management is looking rather the worse for wear, as a result! ;)