Reminds me of a post I wrote last week in my own blog:
http://www.cookbookpeople.com/blog/2007/09/08/the-top-3-family-cookbook-mistakes/

I’ll be posting a link to this story today in my blog.

Everyone who votes “yes” without reading the cookbook… well if they “stand to financially benefit from participating in any standards development activity” – they can be sued for anti-competitive activity and can be forced to pay not just for economic damages but also for punitive damages.

Are all these “new members” aware of that ?

If costs is th reason for refusing the changes, then it is a short sighted decision. Refusal to change is costing a lot in lobbying effort to get OOXML pass ISO. It is risking their office business by making obvious the technical weakness of Microsoft offering. Is all the grief worth the savings in development costs?

I wonder if refusal to change hasn’t more to do with the time required to implement change? Microsoft need to have a standard now. They need to have a credible alternative to ODF immediately. If they take too long writing OOXML those pesky governments may mandate ODF in the mean time.

I also wonder if refusal to change also has something to do with how brittle the Microsoft Office formats are technically. Compatibility with the installed base my be broken. If that happens, customers may be tempted to say OpenOffice.org is as compatible as Microsoft product with the existing documents.

http://en.wikiquote.org/wiki/Steve_Jobs

OOXML’s defects are nothing new. They are carryovers from the legacy binary formats and direct transcriptions of the internal representations that Office uses. Many of them are old as the hills. Due to resource contraints (money) they weren not retooled into proper XML. Newer analogues were not available, and rather than cut features (and kill the ability to represent legacy documents), Microsoft simply clothed them in angle brackets and dumped them into OOXML.

Check out the following article:
http://www.joelonsoftware.com/articles/fog0000000014.html

If fixing minor bugs is so pricey, then imagine how much it would cost to, e.g.:
- fully re-implement field codes in Word as XML constructs
- replace the Word VML engine with DrawingML
- adjust all Excel date formulas to delete an erroneous leap year

These would be multi-million dollar projects!

But doesn’t that just raise the question: why did Microsoft give them such a big, pointy stick in the first place?

I mean, they COULD just fix the technical problems with the standard, instead of trying to force-feed it through the ISO.

In fact, since there are fewer than 1700 OOXML documents on the entire web (according to a Google search by file type I see only 923 DOCX files) I seriously question whether these 1700 companies are even using OOXML today!

In any case, you’re free to discuss my motivations until you grow blue in the face. But this does not change the fact that OOXML is deeply flawed and should never have been approved by Ecma in this state, and certainly should not be approved by ISO.

As for me producing 83% of the objections, thanks for that info. I must admit that I was not keeping score. But I’d note that almost all of these comments were accepted by the committee, by consensus, including by Microsoft and their allies. Around three others on the committee also submitted comments.

I observe that those who had worked on standards previously and were long-time members of V1 tended to submit comments, while those who joined at the last minute, who lacked such experience, did not. I can’t blame them. It is hard to join at the last minute, try to work within an unfamiliar ISO process and a 6,039 page specification that you haven’t read, and be able to participate fully in the proceedings. Rushing committee members is ultimately as unsuccessful as rushing a standard.

sadly the Mac Office can’t implement the OOXML spec either so they’re simply porting the Windows code across.

There’s various links in the following post:

http://shebanation.com/2007/05/16/ooxml-and-the-mac-more-bad-news-from-microsoft/

I think there is one other interesting thing that comes out of the following paragraph:

“Back when I edited cookbooks, I made sure that we set up a test kitchen and verified every step of every recipe. We cooked, revised, and cooked again until we could say that every recipe worked as written.”

No-one, not even Microsoft has implemented the OOXML spec.

By that, I mean that MS has not taken the spec and created an implementation from it. Quite the reverse. They created the implemenetation first, and then generated the spec by simply describing it.

Now, I’ll agree that most standards do this up to a point, in that an initial implementation (or two) is often developed alongside the spec. But almost never does the spec merely describe an implementation and leave it at that. Instead, the spec is discussed, debated and cleaned up, and changes are fed back to the implementation(s). And as these changes are fed back and the implementations are altered to follow it, it becomes more obvious where parts are under-specified, badly-specified or even over-specified.

No-where have I seen a single shred of evidence that any part of OOXML has had this kind of feedback from an actual implementation being written to follow it. MS has merely attempted to described their implementation. Neither they, nor anyone else, has managed to create a full implementation from the spec. And that means that no-one has yes demonstrated that it is *possible* to build an implementation from the spec.

Until that happens, possibly with Mac Office (I think that’s likely to be the first complete implementation) it would seem to me to be pretty hasty to send the spec for standardisation.

Apt. Excellent!

Jason-

Your point is…?

Anyway – again, my compliments on a really creative posting.

Jason Matusow
blogs.msdn.com/jasonmatusow

I love these pieces. It’s just a shame that, as far as I can tell, Microsoft & ECMA steadfastly refused to incorporate *any* comments into the standard.

The only reason I can think of for this intransigence is that they do not want to touch their source code (which entails high costs.) And this is precisely the point where “The Cookbook” falls short. Documenting the recipes is not enough. Fixing OOXML also means *changing* the recipes.

(E.G., not documenting but getting rid of bitmasks, inconsistencies in data representation, erroneous definitions, file system dependencies, etc.)

You rock.

–walter