Slashdot Mirror

according to an OASIS committee member and chief architect of ODF at IBM, it's impossible to write a foolproof spec - if someone wants to be compliant, but not interoperable with other implementations, they can always find a way.

Complying with a standard is the barest beginning of achieving interoperability. MS are trying to wriggle out of what they are obliged to do by equivocating compliance with interoperability, and say "we followed the standard so we've done what we have to", when they know damn well that this doesn't even scratch the surface of interoperability.

There are a vast array of multiple interpretations of even the most painstakingly defined spec. Being interoperable is not about making your own fresh interpretation, it's about catering to the interpretations made by the software that you're trying to interoperate with.

In the case of the missing definition in ODF 1.0, MS should have looked at how all the other implementations handled it, and picked the options that would have worked with the largest number of existing implementations.

They did the opposite.

You are equating bugs to features.
http://www.robweir.com/blog/

Has Microsoft done a single interoperability test?
I bet they have - to ensure it does not interoperate.

Is there bugs in other suites using ODF?
Certainly, and I am willing to bet they work to resolve those problems ... and resolving means that they try to interoperate.

So saying "Microsoft is not the only one" is extremely lame as Microsoft is certainly the worst (at least by Mr. Weir's tests)
http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html.

You are equating bugs to features.
http://www.robweir.com/blog/

Has Microsoft done a single interoperability test?
I bet they have - to ensure it does not interoperate.

Is there bugs in other suites using ODF?
Certainly, and I am willing to bet they work to resolve those problems ... and resolving means that they try to interoperate.

So saying "Microsoft is not the only one" is extremely lame as Microsoft is certainly the worst (at least by Mr. Weir's tests)
http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html.

Before you judge on this issue, it helps to read comments by various involved parts - those raising the issue to attention, MS people who have implemented ODF, and informed commenters outside this dispute. So, here's a bunch of links to start with.

First of all, a series of blog post by OASIS' Rob Weir (who's criticizing MSOffice) and Microsoft's Doug Mahugh (who's defending it) that evolved into a kind of a public discussion on the issue. Here they are in chronological / meaningful reading order:

http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html
http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx
http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html
http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
http://www.robweir.com/blog/2009/05/battle-for-odf-interoperability.html

Then there's some outside commentary. I've taken the following links from comments in Doug's blog posts, and they tend to either be neutral or side with MS on this, so it may not be a representative sample. If you have any representing informed argument for the other side (e.g. by members of ODF committee, or ODF implementers - in general, people who know the ins and outs of the spec, and can accurately judge on its wording and intent - not random blogosphere FUD from either side), please mention them in replies.

http://ajg.math.concordia.ab.ca/?p=4
http://adjb.net/post/Notes-on-Document-Conformance-and-Portability-4.aspx
http://broadcast.oreilly.com/2009/05/odf-11-formula-support-in-office-sp2.html

Before you judge on this issue, it helps to read comments by various involved parts - those raising the issue to attention, MS people who have implemented ODF, and informed commenters outside this dispute. So, here's a bunch of links to start with.

First of all, a series of blog post by OASIS' Rob Weir (who's criticizing MSOffice) and Microsoft's Doug Mahugh (who's defending it) that evolved into a kind of a public discussion on the issue. Here they are in chronological / meaningful reading order:

http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html
http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx
http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html
http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
http://www.robweir.com/blog/2009/05/battle-for-odf-interoperability.html

Then there's some outside commentary. I've taken the following links from comments in Doug's blog posts, and they tend to either be neutral or side with MS on this, so it may not be a representative sample. If you have any representing informed argument for the other side (e.g. by members of ODF committee, or ODF implementers - in general, people who know the ins and outs of the spec, and can accurately judge on its wording and intent - not random blogosphere FUD from either side), please mention them in replies.

http://ajg.math.concordia.ab.ca/?p=4
http://adjb.net/post/Notes-on-Document-Conformance-and-Portability-4.aspx
http://broadcast.oreilly.com/2009/05/odf-11-formula-support-in-office-sp2.html

Before you judge on this issue, it helps to read comments by various involved parts - those raising the issue to attention, MS people who have implemented ODF, and informed commenters outside this dispute. So, here's a bunch of links to start with.

First of all, a series of blog post by OASIS' Rob Weir (who's criticizing MSOffice) and Microsoft's Doug Mahugh (who's defending it) that evolved into a kind of a public discussion on the issue. Here they are in chronological / meaningful reading order:

http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html
http://blogs.msdn.com/dmahugh/archive/2009/05/05/odf-spreadsheet-interoperability.aspx
http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-odf.html
http://blogs.msdn.com/dmahugh/archive/2009/05/09/1-2-1.aspx
http://www.robweir.com/blog/2009/05/battle-for-odf-interoperability.html

Then there's some outside commentary. I've taken the following links from comments in Doug's blog posts, and they tend to either be neutral or side with MS on this, so it may not be a representative sample. If you have any representing informed argument for the other side (e.g. by members of ODF committee, or ODF implementers - in general, people who know the ins and outs of the spec, and can accurately judge on its wording and intent - not random blogosphere FUD from either side), please mention them in replies.

http://ajg.math.concordia.ab.ca/?p=4
http://adjb.net/post/Notes-on-Document-Conformance-and-Portability-4.aspx
http://broadcast.oreilly.com/2009/05/odf-11-formula-support-in-office-sp2.html

Old Buck, actually. Yes, we're replying to each other's posts. Thank the Maker we don't have to deal with properly decoding MS-ASCII... yet. I'll still bet my browser looks different than your browser.

Certainly you've seen Rob Weir's assessment that Microsoft's Office ODF Plugin was completely non-interoperable with ODF. Office writes its own flavor of ODF and fails the read and write tests in both directions where everything else appears to work, or is at least on the road to debugging. I doubt that was an accident. ODF has a "sow's ear" quality to it anyway, but this has to be deliberate from Microsoft. Bravo on their effort to turn ODF into MS-ODF.

If you're living solely inside the Microsoft castle walls, of course everything will work. Well, maybe most things. SNMP and SMTP are protocols, but if you stuff them with unexpected glop, there go your abilities to interoperate. Rewind the clock a few years and try using a platform other than Microsoft's to see web pages or read email. Sure, SMTP from Outlook and Exchange works but you'll be presented with this winmail.dat bullshit instead of an RFC compliant email message. Why do they do that? It's just an RTF attachment but that would be too standard.

Or take good old IE which worked well only with Microsoft's server extensions creating a client-server relationship with the "browser" instead of stateless exchange standards as intended. It's HTTP, right? It's what's inside that counts and it isn't standard and IE is only partially a "browser". Front Page wrote broken HTML that only IE could decode properly, somehow. The goal was that everyone would see a blank or broken page on the internet unless they were using a complete chain of Microsoft technology. Interoperability is not in Microsoft's interests. Never has been. There was plenty of overlap between browser standards and what Microsoft was doing, enough to see something on the Internet, but even that was crafted to make everyone else's browsers look illiterate. Eventually, everyone reverse engineered what they were doing but we're still digging out from it.

Java? You don't think Microsoft torpedoed Java? They released Visual Studio 6 which was Java sans cross platform functionality. No, Microsoft has done a lot to kill compatibility with their products. It's so crazy that people say Microsoft is open and standard. Yikes. They'll supply the programming tools, the protocols, the servers and the clients - even the operating system but nobody really knows what's going on inside. It's certainly very accessible and the tools are very good but it isn't standard. One patch and everything turns proprietary.

If Microsoft actually used standards, they would be compatible with 100% of everything else using standards. Instead, they're compatible with only 80% of everything else. Perl is one of the few areas that Microsoft is behaving. Good call on that. At least ActivePerl for Windows is just an effort to make Perl work better on Windows but Microsoft's actions with Perl are more puzzling than "normal" considering their track record.

If Ubuntu/Kubuntu was merely about attempting to create a free replacement of the Windows API, it would be like skipping the embrace part altogether. It's impossible to stay compatible with Windows software (just think about the ODF perversion) and there always will be a new API with undocumented/patented/DMCAed extras such as DirectX 11, DotNet 4.0, WMA, ...

I think Shuttleworth has said something like this in the past: We need to be good at things where proprietary software can't or doesn't want to go and we need to do this again and again.

Most of you will know this anyway:

• multi-level APIs which are not trying to hide the inner workings of the implementation
• well-designed tools (no feature creep to justify high licensing costs)
• import and export of data (vendor lock-in unnecessary)
• use compiler optimization (processor-dependent optimization, profile-based optimization) since the source code is available
• ...

no, they are doing it right instead of implementing a broken spec.

As far as anyone can tell, the OpenDocument Foundation was basically a Microsoft shill. As other people have pointed out, they had no role in hashing out the OpenDocument formats. Their bait-and-switch tactic makes me highly suspicious that they ever had interoperability as a goal. More info here.

As for the formula specification: Microsoft could have easily downloaded one of a half-dozen format parsers with source code for ODF to test their own parser against. Just because the spec doesn't describe all of the features ad-nauseum is not a reason for not implementing it correctly.

I should point out that the convention with the RFC process is to have a working implementation first; that implementation is essentially the reference. I doubt Microsoft has ever had any difficulty implementing an RFC despite not having a formal standards document. Probably because, in that scenario, Microsoft is introducing a competing product as opposed to the current scenario of being asked to interoperate with a newcomer. They're clearly in a position of strength, and do not want to give that up. Providing an technically correct implementation that nonetheless does not work allows them to say to governments: hey, we complied like you asked, now please keep buying our stuff.

The reason for this is that it's a hard problem

I don't think you can really use that blog post for that citation, because it's the same source as TFA which is both more relevant, and substantially newer... and which says:

We might [also] hear concerns that supporting other vendors' ODF spreadsheet formulas cannot be done because this formula language is undocumented. The irony here is that the formula language used by OpenOffice (and by other vendors) is based on that used by Excel, which itself was not fully documented when OpenOffice implemented it. So an argument, by Microsoft, not to support that language because it is not documented is rather hypocritical. Also, the fact that the Microsoft/CleverAge add-in correctly reads and writes that legacy formula syntax shows not only that it can be done, but that Microsoft already has the code to do it. The inexplicably (sic) thing is why that code never made it into Excel 2007 SP2.

Editorial [brackets] and note mine.

In summary: Your source, the same person who wrote the article which explains why it isn't hard also says Ecma dropped the ball. (in your link.) Another particular gem, this time from the current FA again: Everyone knows what TODAY() means. Everyone knows what =A1+A2 means. To get this wrong requires more effort than getting it right. So to say "The trouble is, it doesn't standardise them - in particular, there's no standard list of spreadsheet functions and what they should do." is just crazy talk which actually apologizes for Microsoft. In fact, there is such a list; the list documents what Excel does, since there was nothing else available; Microsoft itself had this functionality in a previous version, and now it is gone. Therefore the trouble is that Microsoft has deliberately broken spreadsheet compatibility in Office 2007 SP2. There is really no other way to look at it. It might not have been the goal (an alternate excuse might be to take advantage of another, newer codebase in order to eliminate some old code which is otherwise unnecessary) but it was trivially testable and therefore is inexcusable.

No, it defines exactly how spreadsheet formulas should be stored. The trouble is, it doesn't standardise them - in particular, there's no standard list of spreadsheet functions and what they should do. The reason for this is that it's a hard problem - so much of what Excel and other spreadsheet software already does is known to be wrong, or makes bad assumptions.

Because apparently it's really difficult:

http://www.robweir.com/blog/2007/07/formula-for-failure.html

Oasis and ODF committees would rather get it right than have something busted and broken like competing suites.

Never ascribe to malice that which is adequately explained by incompetence

Of course, I am not that cynical. I was taught to never assume malice where incompetence would be the simpler explanation. But the degree of incompetence needed to explain SP2's poor ODF support boggles the mind and leads me to further uncharitable thoughts. So I must stop here.

from the referenced article....
http://www.robweir.com/blog/

Has anyone posted this yet? http://www.robweir.com/blog/2009/05/update-on-odf-spreadsheet.html In it they test ODF-spreadsheet compatibility across different applications including offcie 2007 sp2. Interesting read

I'm in the real world, where I didn't say anything about PJ not being level-headed or insightful in absolute terms. I just said that Andy Updegrove is a bit more so. That was in the context of document standards, of course. That is much more his area of expertise than it is PJ's.

PJ was very level-headed and insightful when the subject was SCO's lawsuits. Her background was very relevant then. On subjects that don't have much to do with lawsuits or the GPL (e.g., OOXML) she often doesn't do as well.

To see what I mean, compare how PJ and Andy blogged about UOF when they first heard about it:

• Andy's blog
• Groklaw

PJ was already declaring victory for ODF in 2006 (before OOXML even got to ISO/IEC) just because UOF existed and there was some people were interested in harmonizing UOF and ODF! If that doomed OOXML, what has all of the fuss in the last couple of years been about then?

Andy is a lawyer and mostly a big picture guy. If you want more technical details, you might want to check out some other blogs, such as Rob Weir's that talk about ODF, OOXML and so on. Rob is a co-chair of the OASIS ODF technical committee, so he knows what he's talking about. As a paralegal turned journalist, PJ just doesn't have the kind of background that bloggers like Rob and Andy have.

The spec is very bad and these are all things that they will be unable to fix until maintenance.

http://www.robweir.com/blog/images/rick.png

OpenXML describes the functionality of every spreadsheet function,

No it doesn't.

whereas ODF has no specification for any spreadsheet functions at all.

Well the above link shows the quality of OOXML's formulas, and here's a real timeline of OOXML and ODF:

In 2005, Microsoft's Brian Jones noted that OpenDocument did not define spreadsheet formulas in detail.[6] However, at the time Microsoft's competing proprietary XML format also did not include this kind of detailed specification for formulas.[7] Microsoft continued to protest that OpenDocument could not be used because it did not define a format for spreadsheet formulas, yet its own specification continued to omit any specification about formulas through April 2006. Finally, in May 2006, Microsoft also began defining formulas in its XML format, fifteen months after the first version of OpenFormula and three months after OASIS posted its first official draft of its specification. -WikiP

By the way, "OpenXML" spelled perfectly every time.. hmm... XML is already Open, and the term OpenXML makes as much sense as OpenHTML. Only Microsoft and their vendors call it that because it's part of a googlebomb on a nonsensical term.

Non-Microsoft vendors just call it OOXML.

That's merely a popular example, read this for more How Many Defects Remain in OOXML

Further, there are mathematical differences between the spec and what Microsoft Office does. Now which do you think an implementor will implement? Your interoperability study is based on reverse engineering, not on following any OOXML specification.

Yet further, there are defects remaining in OOXML that were not addressed and that prevent interoperability. When you try to make a specification in such a short period of time this is to be expected.

Further, there are mathematical differences between the spec and what Microsoft Office does. Now which do you think an implementor will implement? Your interoperability study is based on reverse engineering, not on following any OOXML specification.

Yet further, there are defects remaining in OOXML that were not addressed and that prevent interoperability. When you try to make a specification in such a short period of time this is to be expected.

Rob Weir's blog post on YEARFRAC()

or faulty mathematical functions:

Proposed Disposition We agree that, as defined, the CEILING function does not follow the generally accepted practice for negative numbers. However, in order to maintain compatibility with the corpus of existing documents that use the CEILING function and rely on its current behaviour, no change will be made to Part 4, Â3.17.7.33 page 2,559.

(but they say that one was fixed in the final spec after the BRM)

Luckily for us, nobody would dare to try push through such a subversive standard ;-)

From the article: "... the only mammoth remaining is Ballmer."

You can certainly tell the mindset of the article author, Paula Rooney, and the person who was quoted, Rafael Laguna. Their idea is that it is entirely acceptable and useful to call Ballmer a "mammoth". As in "woolly mammoth" who will go extinct soon, I suppose.

It makes a far better contribution toward showing why Microsoft's management policies should be disrespected if there is some logical substance to what is said.

In my opinion, both Gates and Ballmer make money by being aggressive. That's what they know. That's how Microsoft has made most of its money, by taking advantage of the fact that most of the customers 13 years ago had little understanding of the computer systems they used. They established closed file formats. The managed using the policy of "embrace, extend, extinguish".

Their business management emphasis is away from making money by contributing something positive. For example, Windows Vista is little more than another version of Windows XP that has been modified to require more CPU power so that Microsoft's principal customers, the manufacturers, will be able to sell more powerful computers.

Quote from the parent: "Oh right, after rigging the ISO process with OOXML and their triumph over open standards they're going to go open source?"

MOD PARENT UP!

Oh right, after rigging the ISO process with OOXML and their triumph over open standards they're going to go open source?

Well, despite all the effort they put into getting OOXML approved, they will (theoretically) implement ODF in the next version of Office.

So what would be evidence of change? Well, they'd need to move to an OSS compatible business model for starters but right now they're still mostly about selling boxes of software. They don't have a services-side in the same way that IBM do. They have some hardware -- the mouse/keyboard/peripherals sell well. The Xbox is about selling hardware below cost but they make it back in SDKs and licensing -- so they couldn't open that.

So there's actually very little of the company whose business model is compatible with open source licensing. That's where you'll see change, if it happens -- not in Bill Gates leaving Microsoft.

The ISO have a special fast-track process which means 9 months to review 6000+ pages and 1 month to review 4000+ pages. The end result of this process is a poor quality text with many non-disclosed areas. When the text is released is we will have to reverse-engineer it in order to find out how to use it.

OOXML has patents and is licensed under Microsofts OSP which means that it's incompatible with open source licensing. The ISO allow patents and small fees per-unit (RAND) so this means that Microsoft could restrict some fundamental freedoms associated with open source and destroy any open source version.

By contrast ODF is compatible with Open Source licensing

So ISO are untrusted now, due to approving a standard that is largely undefined, and instead people are moving to the W3C and OASIS.

More specifically it wasn't just the ISO, it's also the IEC and the ITTF that are now untrusted because of OOXML.

The public sector has those concerns too (especially accessibility wrt equality/human-rights), but it's also to do with not favouring one company over another (just like web standards) and OOXML clearly favours one company in that the specification has undisclosed information that can only be explained by Microsoft.

Does that help answer your question?

The public sector has those concerns too (especially accessibility wrt equality/human-rights), but it's also to do with not favouring one company over another (just like web standards) and OOXML clearly favours one company in that the specification has undisclosed information that can only be explained by Microsoft.

Does that help answer your question?

I applaud ISO for recognizing the evaluation of the technical community it servers.

Heh, good one! The fast track process was completely inappropriate for OOXML. With 9 months to review 6000 pages the technical community had only scratched the surface of what's broken in OOXML.

No one in the technical community is happy with the quality of OOXML -- even Microsoft can't implement this thing.

ISO wrote:

According to the ISO/IEC rules, a document which is the subject of an appeal cannot be published as an ISO/IEC International Standard while the appeal is going on. Therefore, the decision to publish or not ISO/IEC DIS 29500 as an ISO/IEC International Standard cannot be taken until the outcome of the appeals is known.

This statement has no bearing on the similar statements issued by South Africa and Brazil in their formal appeals that they should have received a final text by now. National Bodies should have received a final text but this is quite different to publishing (which is all the ISO are talking about in that final paragraph).

Section 13.12 of the directives reads,

"In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and final DIS text in case of acceptance."

The BRM was in February and the final text was due in late March. It still has not arrived. You might call this evidence of the OOXML text being in an unreleasable state (read: a mess) and South Africa would agree...

"Given the magnitude of the specification and the number of identified edits required it was clear that this directive [13.12] could not have been met. This is the clearest possible indication that DIS 29500 as submitted by Ecma and as modified by the BRM is not ready for fast track processing." -- http://tinyurl.com/4ceags

I also hear a lot of "OOXML is proprietary" - this just isn't true. It's XML text in a ZIP file, much like ODF. I also hear a lot about patents, which is the same issue - Microsoft's patent pledge is almost identical to Sun's patent pledge (what, you thought ODF was somehow less encumbered?)

So, when you do come up with a good argument get back to us. Repeating yourself as many times as you have proves nothing.

Actually, it hasn't been debunked at all. There doesn't actually exist a version of OpenOffice.org which actually generates documents compliant with the ISO spec, but that's probably not all that bad (providing the "subsequent versions" which haven't been looked at by ISO don't go overboard).

By contrast, the only thing preventing MSO from writing 100% compliant transitional OOXML is their insistence on using "true/false" instead of "yes/no" (or is that "on/off"?) - as noted here where Rob Weir actually makes a comment that only one change (or very few) would be needed to Office 07 to make it generate valid OOXML.

Those with decades of content in Microsoft Office need to continue buying Microsoft Office to access it with high-fidelity, and theiy pay Microsoft 12 billion each year because of a lack of competition caused by file-format secrets.

It's not a level playing field due to the lack of standards and for years now the big companies and countries who each page hundreds of millions have been wanting competition. They want to be able to choose other products but Microsoft just demonstrated at the ISO, quite clearly, that they will not let their customers choose. Microsoft will maintain their secrets and will scam the system to prevent people going elsewhere with high fidelity.

Governments are sick of it and governments are going to strike hard.

And that no one can actually use OOXML as Microsoft acknowledge by saying that they're not going to implement it until 2011?

Grow up and stop blaming geeks for Microsoft's poor actions and the geeks calling them out for it.

And that no one can actually use OOXML as Microsoft acknowledge by saying that they're not going to implement it until 2011?

Grow up and stop blaming geeks for Microsoft's poor actions and the geeks calling them out for it.

> I agree that Excel isn't enough, but don't dismiss Excel as a tool.

I think it is pretty well documented why Excel should not be used as a serious scientific tool - it will corrupt data, it is incorrect, and inconsistent (pdf) - all bad for science. I am surprised accountants are allowed to use it.

And it does not seem to be getting better either. So why should scientists be encouraged to use such an incorrect tool? Because it is easier?!?

The US technical committee INCITS V1 was stacked. Check that site for a graph of late joining members who suddenly voted for OOXML.

That the final specification text for OOXML is not available when it was due May 1st (or March 29th, depending on who you listen to) shows how the ISO aren't following their own rules. It also shows that there are a lot of problems getting OOXML into a state ready for public consumption because it's of such poor quality, that it was a premature abortion of a standard in no fit state to be useful to the world.

The ISO/IEC JTC1 and SC34 are now deprecated. Realy standards are made at OASIS.

Sorry, my mistake I had misread this post on Rob Weirs blog.

Hi,

They've either documented or removed those 'behaveLikeWW8' style flags. As engineering criteria however the documentation hasn't been reviewed to see whether it accurately describes Microsoft Office, and it was added late in the process (early 2008, I think).

What remains however are Microsoft OLE references without documentation or patent coverage, accessibility problems, and huge areas of OOXML entirely without documentation that mean that ISO OOXML promotes defacto standards.

Read my blog for a few posts on how no one voting on OOXML saw a final specification.

Really?

You mean to say that YOU have seen the final version of the OOXML format, when nobody else has and ISO is late in publishing it?

http://www.robweir.com/blog/2008/05/release-ooxml-final-dis-text-now.html#links

Wow, you must be magic. Or Alex.

OOXML is not documented enough to be interoperable. As it's not documented then your claims of benefits are without merit.

It all hinges on the quality of the text and whether that describes Microsoft Office's file format. As OOXML doesn't describe Microsoft Offfice then all of your points a moot.

The undisclosed areas of OOXML are so numerous that to fill in the undisclosed areas of OOXML you end up reverse engineering Microsoft Office. We're little further along than we were before this so-called standardisation. Only now OOXML gets to pretend to be documented despite the numerous problems that remain in OOXML. There is a world of difference in the scope of problems here... a distinction between what can be solved in maintenance and what are problems that are so numerous and mean the standard is unfit for any implementation. Read Tim Bray's new comments on OOXML

• The ISO members (the JTC1 committee) found 3522 defects in the OOXML standard
• The Ecma grouped these complaints and proposed 1027 changes on about 2300 pages
• Microsoft said they had adressed 662 of the proposals
• At the isos ballot resolution meeting (BRM) 900 of the 1027 proposals were not checked (they didn't check if MS had implemented the changes)
• Rob Weir used a random sampling technique to estimate how many proposals were actually implemented: about 1.5%

Maybe they wrote the article in "OOXML Text", converted it to "OOXML Sheet" and finally converting it to "OOXML Presentation" before exporting it to HTML.

See http://www.robweir.com/blog/2008/03/disharmony-of-ooxml.html.

OOXML internally follows a standard which, I think, is very much similar to ISO. heh

Your post makes no sense. 75% of P members voted in favour, which is 58% of P members? How could the percentages change? Are you mixing up committees with JTC1?

Then you go on to say that new O members joined specifically to block it which is factually incorrect.

See this graph on P members voting and the sudden increase in membership for approval http://www.robweir.com/blog/images/p-members.png

And this post with a table on new vs old members and how the new O members (mostly small African nations) joined to vote for OOXML,

http://www.robweir.com/blog/2007/09/how-to-hack-iso.html

If you have any references to back up your ridiculously incorrect numbers please share them, but we all know that you don't actually have any.

Your post makes no sense. 75% of P members voted in favour, which is 58% of P members? How could the percentages change? Are you mixing up committees with JTC1?

Then you go on to say that new O members joined specifically to block it which is factually incorrect.

See this graph on P members voting and the sudden increase in membership for approval http://www.robweir.com/blog/images/p-members.png

And this post with a table on new vs old members and how the new O members (mostly small African nations) joined to vote for OOXML,

http://www.robweir.com/blog/2007/09/how-to-hack-iso.html

If you have any references to back up your ridiculously incorrect numbers please share them, but we all know that you don't actually have any.

If you're looking for "compromises", you should look at OOXML, not ODF. Rob Weir shows that OOXML is full of a massive number of errors - I estimate over 172,000 unresolved errors. These comments about ODF are without merit; OpenDocument can handle change requests (see, for example, section 4.6) and tables in presentations. OpenDocument 1.0 handles tables-in-presentations just fine, they're just encoded differently than you seem to be expecting. Embedded tables are encoded as embedded spreadsheets; this is slightly different than how OOXML encodes it, but all the data and capabilities are there. OpenDocument 1.2 will make the indirection optional, but this is all invisible to end-users anyway. Note that this means that tables CAN be in presentations, but more importantly, they're encoded the same way that they are encoded in other kinds of documents - OpenDocument has a single, clear table model. In contrast, OOXML has multiple incompatible table models. OpenDocument is remarkably consistent, as well as building on well-established standards - which is why it can be so much smaller, and so much more capable, at the same time.

Sure, many office suites will implement some subset of OOXML. But it would be wise to view it as a temporary transition format, so that you can escape from vendor-specific formats to an open standard like ODF. Yes, it's convenient to have it as a "published standard", but Ecma is enough for that; there's no reason to have an ISO stamp on it. OOXML is essentially the proprietary format of a single vendor. There's no reason to confuse anyone into thinking it's some sort of universal format, and the ISO stamp is likely to cause that kind of confusion.

The format for documents should not be controlled by any single office document supplier. That is a key reason why OOXML should be rejected by ISO, and published only by Ecma as some sort of interim format (to enable people to move off it). OOXML is also so error-ridden that it should have been laughed out of the fast track process.