I hope OOXML dies and Microsoft with it... although the second one will not happen anytime soon.

But I am patient, I can wait.

I cannot deny that ODF* is quite long and confusing. It'd be much nicer if it could be trimmed significantly...then again I wouldn't waste my life reading all the content either so I really don't know how much can or should be trimmed for sure.

"*OOXML"

EDIT: Yeah, I meant to say that, Paul :D

*OOXML

"The Linux Foundation" says it all for me really.

Microsoft will not implement ODF because it solves backward compatibility.

Microsoft depends on backward compatibility problems to drive sales and will not support any standard that does not propagate backward compatibility problems into the future.

Scotch Moose,

Anyone who knows the least thing about Microsoft (obviously not you) knows that backward compatibility without problems is probably their most important consideration. (For example, you can still open Word 1.0 documents from within Word 2007 without issues).

Also, anyone who has looked at the question of ODF and its ability (or inability) to represent Word documents knows that ODF has very considerable problems properly representing Microsoft Office documents. There are very detailed lists of such issues on the web; many of these issues are real showstoppers.

So, I have rewritten your comment to conform with these facts:

"Microsoft will not implement ODF because it does not in any way solve backward compatibility.

Microsoft depends on backward compatibility to drive sales and will not support any standard that does not solve backward compatibility problems into the future."

Obviously he is here to spread fault information. And many readers have no clue are actually believe it in. Just like how the Mac is better than PC because it can runs Windows while PC cannot run OS X.

"you can still open Word 1.0 documents from within Word 2007"

But can you open a Word 2000 document with Word 97? No, you have to get an upgrade.

Backword compatible software means keep paying us money so you don't get error messages.

Backword compatible file formats means old software can open new files without error messages.

"ODF has very considerable problems properly representing Microsoft Office documents."

That's because Microsoft has not implemented ODF. You might have intended to say OpenOffice has some problems with Microsoft's proprietary file formats.

I still have some Word 2000 documents around here and not a one cannot be represented, perfectly, with ODF. But until they are converted to ODF, a format that really eliminates the incompatible file format errors, they look kinda funny in OpenOffice. And that is because of the old Word file formats that OOXML wants to wrap up in XML and carry around forever.

"But can you open a Word 2000 document with Word 97? No, you have to get an upgrade."

OMFG, you gotta be kidding me.

FYI there are few differences, if any, between Word 97 docs and Word 2000 docs specifically...but anyway, that's what those compatability boxes are for under the save options.

So we should just always select the oldest format available and then we have compatibility.

Scotch Moose,

You clearly don't know the difference between backward and forward compatability. Your latest comment in effect says that Word does not have backward compatability because it does not have forward compatability! That is nonsensical logic.

And, besides, Word (and the other members of Micrsoft Office) DO have forward compatability. All you have to do is to spend a minute downloading and installing a free addon from Microsoft for, say, Word 2000 to give it the ability to read and write future formats (Word XP, Word 2003, Word 2007).

So, in short, you are completely wrong.

Scotch Moose,

One last item. I am glad that you have admitted that ODF fails to properly represent Word documents. However, to say that the reason this happens is that "Microsoft has failed to represent ODF" is just plain nonsense.

The real reason is that ODF is based on the capabilities of OpenOffice, which has many points in which it does not have the capabilities that Micrsoft Office has. (This fact is easily checked with a short web search.) As a result, the creators of ODF felt no compunction to add to ODF's file format the ability to represent those missing capabilities. These include the following showstoppers:
- No ODF specification for what a valid spreadsheet formula is (can you believe this!?)
- No ODF specification for how tables are included in Presentations

Gee, maybe Microsoft could have contributed to ODF and addressed those issues.

And do the work that the standard writer should have done? I would rather microsoft continue to improve their own product instead of writing the standards for a competing product.

No, as he said, you select the COMPATIBILITY CHECKBOX and you will be able to open said document in word 97 without the extra added stuff from word 2k.

The standard writer was a consortium of many companies that are willing to compete with each other on the merits of their products. I understand that Microsoft doesn't like that kind of level-playing-field competition. It is so much easier to prevent interoperability and lock customers in.

This is the first time I have heard of this "free addon". If it's true that would be nice.

There were some recent stories in the news about scientific publications refusing to accept submissions in Word 2007 format. Somebody should tell them about this too.

He said "under the save option". Thanks for paying attention.

*Checks MS Word to find the option again*

Actually, it is under the Compatibility tab. My bad.

In Word 2000 I recall it was under the "Save" tab. Again, maybe I'm not remembering correctly. Anybody have Word 2000? Where is the option to save files as Word 97/95 compatible documents at?

Scotch Moose,

Once again, you have little knowledge of what has actually happened in the standards process. Rather than the "consortium of many companies that are willing to compete with each other", ODF was almost exclusively standardized by two people, someone from Sun and Garry Edwards of the ODF organization (go Google him and find his blog for the full story).

By contrast, OOXML much better fits your description, since it was standardized by a group of about 20 companies and organizations who were part of the ECMA technical standard committee. This commitee included Microsoft competitors including Apple and Novell. It was done this way precisely to *improve* interoperability.

And before you tell me it was all just done by Microsoft (with the ECMA just rubber-stamping a Microsoft draft), check out the facts for yourself. You will find that in its development of OOXML, the ECMA committee made substantive changes to the format, and in response, Microsoft's developers were contantly updating their Office 2007 code to keep up so that it supported the final OOXML standard.

So, once again, you are completely wrong (and everyone can check this out for themselves)

I thought everybody who ever used Microsoft knows that Microsoft *always* provides free utilities to allow users of older versions to read and write the latest format. Perhaps you aren't a user of Microsoft Office?

In case you are, you really should go over to the Microsoft Downloads site and look at the free downloads for Office there.

You fail to mention another reason why people struggle to implement perfect .DOC translation is because Microsoft keep the document format under wraps. Anyone who tries to add this functionality has to reverse engineer it.

So much for interoperability!

Ok, who actually made the Ecma 376 balloned to 6000+ pages? The culprit is IBM. IBM submitted plenty of comments thus the original 2000+ pages specification expanded nearly 3 times the original size before becoming Ecma 376.

IBM knows that Microsoft responds well to comments, that's why IBM tried hard to make ISO rejects OOXML with NO without comments. Anything less than that and OOXML is good as in.

huh? Any links to back that nonsense up?

6000+ pages and still incomplete with references to internal Microsoft specifications and formats. The problem with the size of OOXML is caused by the mountain of code that implements OOXML not by the people that want it properly documented before it becomes a standard.

Let's clear up a few misunderstandings here.

The draft OOXML specification from Microsoft ballooned from 2000 to 6000 pages *not* as a result of comments from IBM (who in fact refused to cooperate and take a constructive part in the ECMA process), but from the ECMA technical committee itself (Apple, Novell, British Library, etc.). The committee felt that the standard would be easier to understand and implement if it included a lot of explanatory and tutorial information. In the end, they added several thousand pages of such material, which in practise is not part of the standard. The ECMA committee then made what is in retrospect a "marketing" error by including all this additional helpful information as part of the actual standard, instead of separating it out completely as supplementary material. They misjudged the extent to which anti-Microsoft zealots would seize upon *anything* to kill OOXML. And, so, one of the things the zealots have seized upon is the fact that the standard (as published by ECMA) has a lot of pages and is thus (according to the zealots) "impossible to implement". This is what the zealots say, even though they actually know that the real part that needs to be implemented is much less than 6000 pages, and that there are by now dozens of implementations completed or in progress. No zealot ever lets the facts get in their way!

As for the statement from asellus about IBM's comments being responsible, he(?) is confused about the comments that IBM came up with *after* OOXML became an ECMA standard. Those comments are intended to stop OOXML coming under the ISO standards umbrella. The reason is if the anti-OOXML campagn suceeds, then governments (who tend to like ISO standards) will be strongly tempted to buy Notes from IBM (which does not support OOXML), rather than Microsoft Office (which of course does).

There are two wrong parts to this statement by Scotch Moose.

1. The OOXML standard is *not* incomplete with respect to internal Microsoft Specifications and formats. The anti-OOXML zealots have noticed that the spec mentions typical types of objects that can be embedded in an WordProcessingML document (e.g., a Word 2007 document). Just like any modern word processor, Word 2007 allows you -- the user -- to include things like a picture image, say a jpeg image. The things you can embed also happen to include items whose technologies come from Microsoft (e.g., an ActiveX object). There is nothing at all conspiratorial about this fact. As a user, you would probably be up in arms if your Word processor did not allow you to embed such "foreign" objects. Now, the OOXML specification (like that of ODF, which does the ***same*** thing), mentions this fact and mentions some popular types of objects to embed. It is not the role of the OOXML specification (or ODF specification, or any other such document specification) to specify the internal formats for the "foreign" embeddable options. That is outside their scope. For example, the ODF specification does *not* include the entire specification for how a jpg picture file is strcutured and formatted! The fact that OOXML does exactly the same thing as other document specifications in that it does not specify foreign object formats has, however, been seized upon by the zealots, to "prove" that the OOXML specification is incomplete. They are lying, of course, and they know it.
2. There is no such "mountain" of code. As has been shown many times over, the OOXML specification allows for conforming implementations that only implement *part* of the standard. So, for example, the code to write an import/export OOXML filter for a spreadsheet is about 3000 lines. This is not my statement, it is that of the coder for the GnuMeric spreadheet, who has just done that. A few thousand lines of code is not much. Further, as Microsoft and others come out with libraries that implement low-level functions, it will in the future probably take less than a hundred or so lines in the future to write a conforming tool.

It's clear you are a supporter of Microsoft's OOXML "standard".

Are you also a supporter of their bribery and corruption to pad votes in their favour?

It's easy to get bent out of shape over this one.

Microsoft is clearly gaming the process and pushing a sub-standard standard through the system.

But I don't think there is much to worry about. The 200 million Novell got for promising to develop OOXML for OpenOffice is not enough. It cost Microsoft a lot more than that and took them 10 years to build that mess.

There will be no vendors other than Microsoft offering OOXML office suites, at least none that will work worth a darn, or that are not 2 years behind Microsoft's version.

If OOXML is made an international standard or not, it will never be able to fill the role of a real standard.

What's the role of real standard? Vendor independence.

It was Massachusetts affair that scared Microsoft into trying to buy itself a "standard". Users would have an effective defense against vendor's lock in strategy by requiring applications to use open standard formats. This is why Microsoft is so keen on buying itself a "standard". It will allow Microsoft to formally get around open standard requirement, while continuing to use lock in strategy with what essentially is still a proprietary format, just as before.

too bad OOXML is not an "open standard"; it is a "closed" standard. Only M$ created it. Only M$ changes it.

That's what I said.

Making OOXML a standard is like putting lipstick on pig. Sure it can be done but I still wouldn't kiss it.

you mean like Java?

The MAD boy is a nothing but a MS troll. His responds are all bias.

And what does "Java" have to do with this discussion?

It doesn't matter how bad it is, all Microsoft needs to continue it's user lock in strategy are words "open standard" next to OOXML.

Linux Foundation? Saying something political?

Wow, the future must have reached the end of their noses.

"parallel standard" is not a standard.

not true. There's many areas where there are multiple ISO standards for the same purpose.

yeah, it's pretty silly that the minutes from the WG and ISO meetings be stored in OOXML, and 5 years from now everyone is wondering why Office2012 can't read the minutes from a few years back.

It's not a MS bashing, it's MS's track record and trends that make this a fact.

ODF has the possibility of breaking backwards compatibility too, but with it being more on the open source side and controlled as such, it would be much harder to break. SO long as it isn't managed by the linux kernel team. they love breaking backwards compat between minor kernel revisions =/

Cheers.

The Linux kernel backward compatibility issues are very limited these days. Fair is fair, now. ;)