It's too bad Microsoft can't let go of dreams of world domination. If they were willing to compete fairly on the level playing field of an open, implementable, standard they would do well and so would many competing software companies.

Even I would be willing to give Word a go-round, if I knew I wasn't locked in and could work on my documents with any vendors products or even my own code. But that is something EOOXML can never give us. There will only ever be one product that completely implements that “standard”. Even if Novell spends every cent it got from Microsoft working on EOOXML for OpenOffice it will never be complete.

zridling & KingMotley: IMO there's some truth in what you both say, but also half-truths and lies (zridling).

Great though open-source software is, there is the mentality sometimes of 'I'm better than you, if it dont work it's your fault'.

In this case Microsoft is trying to 'meet the customer where they are at': providing backwards OpenXML compatibility, and ability to load/save OpenOffice's ODF.

What have the developers of OpenOffice done?
Answer=Nothing (Novell are only working on it since Microsoft have paid them)

Why doesn't the OpenOffice project try and tackle the issues?
Answer=their mentality shown above (they have 'good enough' support for doc/xls to get people to try OO, so they no longer care - adopt our standards, why should we be compatible with yours)

zridling: Why post over at FileForum at well? That looks like fanboy behaviour.

sumone: yeap, Microsoft still have a long way to go! I'm just glad they now do seem to be trying.

.doc files aren't a "standard", just vastly commonplace. Where's the files available that tell you how to be interoperable with the DOC format?

I'll tell you where - nowhere!

You have to reverse engineer every little oddity Microsoft keep building into it. And that's not particularly easy.

By comparison, ODF is open, so there's no real challenge to adding support to any WP to have the ability to import / export files as ODF.

I guess your definition of "standard" differs from most other people.

I guess the new OpenXML formats should meet even your stricter definition.

The classic example of a standard is the firehose. You can't have the firemen show up only to discover the fire hydrant outside your house uses a different connection than their hoses. Standards allow all manufacturers to build truly interoperable products. Standards bodies exist to make sure the standards are of good quality and will achive the goal of interoperablity. A standard that can have only one implementation is useless.

IMO a 'standard' has to take into account what already exists in the marketplace.

Using your example, say the dominant fire hyrant used was made by one company to their design (Microsoft/"doc" files). Thus, the other companies around at the time decided it was best to copy the designs, rather than continue 'ploughing their own field' (achieved by observation rather than access to the blueprints). All worked 'fairly' well.

A few years later the competitors started dying off.

A new group established itself (OpenOffice) and decided to define a fire hose 'standard'. It knew it needed some level of compatibility to break into the market, and so provided such: a way to get 'most' hoses connected to 'most' hydrants.

However, he's the crux of the matter, it doesn't work all the time. Imagining the outcome, who's to blame?

Furthermore, the dominant company who make by far most of the hydrants decide to introduce their own 'standard'. They publish the specs. Yet the 'standards' company (OpenOffice) doesn't want to co-operate, believing their 'standard' the better. Surely, isn't this considered arrogant?*

(*: yes I know Microsoft is rather arrogant in most matters, but it does appear, to the layman, that in this case it is making the right steps, unlike OO).

Really MS? Then show us your "interoperability by design" with W3C standards in IE and JPEG2000 and MPEG-4 standards in Windows.

My results were less than spectacular; in fact, the 'translator' failed miserably. Microsoft, et al. should be thoroughly embarrassed. Why bother? Just get the real deal instead.

As for this paragraph:
Microsoft notes that OpenDocument still has gaps that are being worked out by OASIS, such as spreadsheet formulas, macro support and support for accessibility options. Citing Open XML's accessibility features for disabled workers, file performance and support for integrating external XML data, Microsoft says ODF "focuses on more limited requirements."

There are too many lies to rebut. To clarify, OASIS has always worked on converting Microsoft Office macros, formulas, etc. Any "gaps" are Microsoft-created because they won't share their source code (their prerogative, no sweat). In fact, OpenOffice Calc corrects many problems with Excel, including the infamous 1900 date fiasco. Now that ODF is ISO certified, however, Word-conversion iss no longer a top priority for OpenOffice. Instead, it's Microsoft who must race to catch up with the OASIS OpenDocument Format (ODF) now. As for accessibility, ODF is way ahead of the curve. Finally, when Microsoft says ODF "focuses on more limited requirements," what Microsoft means is that ODF is built for the future, not for all past formats, as Microsoft has spent the last dozen years frantically trying to do.

Obviously zridling you are just a fanboy spreading more FUD. I suggest you actually go and read the documents (Both, ODF, and OOX). You'll quickly see that the ODF spec is quite lacking in depth.

"the infamous 1900 date fiasco" is only a fiasco if you are trying to read the actual file without a full complete understanding of what is being stored. It's fully documented in the OOX spec. Microsoft isn't racing to "catch up" the OOX spec handles everything the ODF spec does plus much more (and is much much more accurate for places that need to read/archive older Office documents to boot).

As for accessibility, I'll defer that to the experts which have said the exact opposite (See the Mass. discussion, even the "Open" camp didn't argue that point very much).

When you say "(See the Mass. discussion, even the "Open" camp didn't argue that point very much). " do you mean Massachusetts and their attempt to force ODF onto all state agencies?

The paragraph quoted is quite straightforward and correct in all respects. There are no *lies*, only a lack of knowledge on behalf of the writer (zriding). OpenDocument has many gaps that according to the ODF group will take several years to fill. The "gaps" were created by the ODF group (Microsoft didn't work on the ODF standard!!!). If the writer knew what they were talking about, they would know that access to source code could would have no impact on writing a standard for a file format.

The writer also engages in the usual inflamatory language ("fiasco", etc) of someone who doesn't know what they are talking about. For example, they don't seem to know that the Excel "date" fiasco did not originate in Excel, but in Lotus 123. Microsoft had no choice but to be compatible with 123 re dates when Excel was first introduced. Since then, likely 100's of millions of Excel spreadsheets have been produced by people around the world, which would all break if the OOXML format did not take into account the antique 123 bug.

Well, you inadvertantly made my point: why didn't Microsoft fix the 1900 leap year date bug (Excel that treats the year 1900 as a leap year) instead of encoding it? Why have they not fixed it for the past 20 years? Changing the Gregorian calendar is not necessary (or the best way) to achieve compatibility with spreadsheets that depend on this bug. A better solution would be to define the spec correctly, and when converting old binary files to the new format, Microsoft Office would (for example) replace WEEKDAY() by WEEKDAY()+1 for any dates affected by this bug. Alternatively, since they have compatibility flags for several other legacy bugs, this could be handled that way as well, e.g., when importing a legacy Excel document, set a flag "LeapYearBug=true", but when creating a new OOXML document this flag would not be set and dates would be described correctly.

Truth exposes lies. When one tells lies in the face of truth, truth hurts. So tossing out your little "fanboy" pejorative doesn't make you right; it makes you sound like a little boy who's taking his ball and going home.

And how exactly is ODF "lacking" in depth? Please give ONE concrete example of how ODF is lacking; that is, a specific piece of information that a global office user will use which is simply NOT possible with ODF.

And why should OpenOffice do Microsoft's conversion work for Microsoft's software? Isn't that backwards? As I stated: ODF is now the ISO international standard of office documents; it doesn't need Microsoft, .doc; .docx; or backwards compatibility. As I wrote, ODF is for the future, not built on layer after layer of backward binary compatibility. Note that it was Microsoft (along with a half dozen companies) that raced to create a conversion filter from OXML to ODF. OpenOffice didn't need — and won't — create an ODF-to-OXML filter. Heck, Microsoft is even paying Novell to create the ODF filter for Office 2007!

It seems you're upset that with ODF as the international standard, there's no need for every word processor out there to write file conversion filters for Microsoft .doc format. ODF is an open standard, open source specification that any vendor or developer can apply to their formats. It's a lot easier to write a conversion filter for a (ODF) spec that contains 600 pages compared to one (OXML) that has almost 7,000 pages.
________________________________________________
Note: I've used Microsoft Word since version 1.0 and have already bought my copy of Office 2007. However, all my documents are saved in ODF because I'm no longer willing to allow a corporation to hold my data and documents hostage to a proprietary format that their own software can no longer read from a few years back.