This morning, MS Word corrupted a document on which I was working. When trying to re-open it, MS Word went in an infinite loop. The work of several days were lost (I had just erased the security copies I’m used to keep to protect against such MS Word behaviour)…

In a desperate try, I opened the document in OOo Writer, saved it again in .doc format, and tried to open the new copy with MS Word.

Result : MS Word happily accepted to work again with the document. To my big surprise, NO formatting was lost ! I just had to delete some strange styles that were not visible before (and which apparently were causing the infinite loop in MS Word).

So much for the “non-interoperability” claims of Open Office !

That said, it’s obvious why Microsoft won’t tolerate any movement towards harmonizing the MS Office specification and the ODF standard. It takes the initiative away from Microsoft, and forces it to behave in a manner quite opposite to “business as usual”.

But the fact that even Microsoft didn’t make any opposition to the standardization of ODF says this: there wasn’t anything they could say. The Office Suite is now one of the best-defined software packages now. Microsoft is now caught in a trap of its own making.

So perhaps what the ODF standardization effort should be looking at is including a set of optional “unique to MS Office” extensions, similar to what OO.org does with a decade’s worth of .DOC, that makes OO.org a much better tool for recovering old .DOC than anything Microsoft currently has on offer.

Microsoft really doesn’t have much to offer in terms of standard harmonization, and there’s nothing to say they won’t treat their current “standard” in future as a minor inconvenience.

It is beta software. Expect some bugs. The first beta release of Lotus Symphony was just a few months ago and we have already released 3 beta updates. I use it on a daily basis and use to exchange documents with people at other companies using OpenOffice without problems. If you mail me your specific document, I can pass it on to the Dev team to look at.

Remember, during the development of ODF (2002-2005) there was no OOXML specification, not even in Ecma, and there was no publicly available binary format documentation for the legacy formats. So what exactly were we supposed to harmonize with?

As for Gary’s conspiracy theories, I’ll just note that Sun has produced a real, working ODF Plugin for MS Office whereas, Mr. Edwards for all his talk about interoperability has failed to produce a working version of his daVinci plugin. So I ask you, who is against Office compatibility: the company that delivers a plugin, or the man who just talks about it?

According to the controversial writings of Gary Edwards Sun was actively hostile to any attempts to harmonize ODF with Office, that they actively fought against anything that could be considered “office compatible”. What makes you think they’ll allow it now?

Parts of this are in place already; http://symphony.lotus.com/ can be downloaded at no charge from IBM’s web site. Apart from the proposition that Symphony carries the IBM brand name onto the user’s screen, why should IBM care whether a consumer uses that application or something else that also conforms with the same standard ?

Well, it would be great if it was as easy as that. But the fact is that it does matter what application you use. The output isn’t the same if you use OO.org and Lotus Symphony.

I have Lotus Symphony Beta 4 and OO.org 2.3 on my computer and ran some tests with the presentation-tool in both applications. I created a presentation with a title slide, one slide with a table (in OO I had to use a spreadsheet object since OO doesn’t support tables in presentations), one slide with an animated draw object and one slide with an animated text-box. I also used one of the standard slide transitions. I saved both presentations in the standard ODP file format.

Ok, here’s what happened when I opened the Lotus presentation in OO:

The text formatting and colours were preserved. The table was converted to an invisible OLE-object. I had to double click on it to edit it as a spread sheet in OO. I had to manually resize the object to try to resemble the table, I had to reformat the text and justification, and had to manually set the cell background to none so the slide background would be visible.

The draw object looked the same in OO but the animation was gone. No sign of it at all. The same happened to the text box. It looked the same but no animation.

The slide transition was preserved but the effect was interpreted differently in OO.

Ok, so far but not so good.

Then I opened the OO presentation in Lotus. All formatting and colours seemed to be preserved. The spreadsheet object was also preserved and behaved the same way in Lotus as in OO. The draw object looked the same, and the animation was preserved. Good! But: The text box looked fine in normal view but in slide show view it was gone. No sign of it at all. The slide transitions worked well though…

So, you say it doesn’t matter what application someone use. I say it does. It matters a lot.

And please explain this to me: Sun and IBM invests lots of time and money to create the ODF standard. And then they spend more money creating one application each that use the same ODF standard. And even then you can’t get it right? Can you blame me for telling my customers to stick with Microsoft Office for at bit longer?

First, a disclaimer. I work for IBM. I do not represent IBM. That said, here’s what I think is going on.

‘Nirvana’ for IBM would be a position where they could sell a solution to a government. It might be to the revenue-raising arm.

The IRS would deploy a tax return to the ‘general public’, as an ODF document. Joe Q Public would fill it in, and return it. The IRS would accept the return, zap it up to their IBM mainframe, process it for the immediate commercial purpose, and archive it for evermore or as may be required by local law.

Nowhere in that is there a suggestion that lack of interoperability would favour the solution vendor.

Parts of this are in place already; http://symphony.lotus.com/ can be downloaded at no charge from IBM’s web site. Apart from the proposition that Symphony carries the IBM brand name onto the user’s screen, why should IBM care whether a consumer uses that application or something else that also conforms with the same standard ? It doesn’t affect IBM’s revenue either way.

Now, we understand that other vendors do have different business models, and may well have commercial interests in not interoperating so well; principally, I suppose, vendors who sell products which are used by consumers.

But for vendors who sell products to large businesses and large governments, ‘standards all the way’. Anything else is a side effect.

I believe, ideally, ‘conformance’ or ‘loose conformance’ should only be given to those applications whose extensions are not critical to the document in question. That is, if you can load *any* output of a ‘loosely conformant’ program into a ‘strictly conformant’ program, you should be able to read and access all of the content. The formatting can be bad, but the content should all be there.

Note that this also means that a ‘strictly conformant’ program should not do anything negative in response to extensions; extensions should simply be ignored (although they should also be retained, and shown in ‘view source’ mode.)

Note that in the above, I do not use ‘should’ in the standards sense of should; I believe that the standards should have ‘MUST’ where I have should.

Regarding the direction of ODF and OOXML harmonization: Harmonization should happen in *both* directions. As far as we can tell, ODF is more malleable, so our efforts are probably best directed there. However, in an ideal world, both sides would sit down at the table, and work out a series of changes to both of their formats that would, in the end, result in the two standards being identical. (Actually, in an *ideal* world, this would never have happened, because ODF came first, and MS was on the ODF committee before MS started OOXML.)

I dived into this extensions topic a bit in my interoperability talk at the OpenOffice.org 2007 conference. My recommendation was that the ODF standard define “conformance” as well as “strict conformance”. Strict conformance means that the implementations use only the functionality described in the standard, with no extensions allowed. An application could then run in a strictly conforming mode, perhaps triggered by a UI setting.

You could also have application profiles to subset functionality further, but I think adding a strict conformance mode is the more direct approach to your concern. Application profiles are more for creating a canonical feature subset for a particular purpose. So, ODF Mobile Profile for mobile devices. But even that could have conforming and strictly conforming modes.

But note that there is a blurry line between vendor extensions and user extensions, especially when we get to the level of semantic tagging and integration of business data. Do we want to forbid a user from structuring their data so it integrates well with an internal business process because it makes their document less portable? No,I think the user should have that choice, which means that the applications and the standards need to support that capability.

In any case, you shouldn’t get too excited about the order of action items processing. We don’t do everything in a simple linear order. Some stuff gets taken up immediately, other stuff lingers. Whether the feature was added yesterday, or whether it was added back in 2005, it really doesn’t matter. It is all standardized at once when we approve ODF 1.2.

“So we’ve agreed that this approach is technically feasible. We’re also agreed that extending ODF outside of the standards process is not a good idea.

…

“This common functionality between ODF and OOXML would also include a common extensibility mechanism.”

So we are to take two so-called “standards” that both allow and encourage vendor and application-specific extensions and combine them into one standard that includes a “common extensibility mechanism?”

Embracing, extending, and extinguishing a standard is embracing, extending, and extending a standard, whether it’s Microsoft, Sun Microsystems, or IBM doing it.

While a standard may legitimately include a mechanism for extensibility, in no way, shape, or form should files containing markup not fully specified by the standard be granted “conformant” status as ODF and OOXML both do.

Moreover, neither ODF nor OOXML require that vendor and application-specific extensions be non-proprietary. The embraced and extended standards can permissibly be armored with software patents.

OOXML at least has the courtesy to say that specifications for extensions “should” be published. But ODF offers not even that suggestion and I still see no progress on that ODF TC action item to move the now unspecified OOo-specific document settings into ODF, even though the proposal was added to the TC agenda back in 2005.

What’s missing from this whole discussion is the need for interoperability profiles, with a defined superset profile and defined subset profiles.

Anything outside of the profiles has to be non-conformant or you simply continue the anti-competitve interoperability nightmares the big vendors have for decades inflicted on office productivity software users.

ODF advocates who criticize OOXML on interoperability grounds are throwing rocks from inside a glass house. It’s the proverbial pot calling the kettle black.

“ODF interoperability” is an utter myth. For supporting documentation and links, see http://www.universal-interop-council.org/?q=node/1

you quote one of the most amusing stories from this whole saga.

If you look at adoption by share of Office and Operating Platforms then those same “corrupt” countries that you point to are more likely to choose Linux and OpenOffice as a platform.

Working on your assumtpion, I have to wonder who is paying them to do that? or maybe it is just poorly collerated data, built into a fictional story to serve somebodies purpose?

Business as usual for them, who are used to push things down the throat of others. Well done, IBM! Please keep it up.

But let me cite a little more from their post:
< <"They are doing this because it is advancing their business model. Over 50 percent of IBM's revenues come from consulting services."
A growing proportion of those revenues are being derived from the support of open source software, he said.>>
What does open source, IBM consulting services and business models have to with technical argumentation against a standard?

They claim that ODF promotes “free software” (actually they call it “open source”), although there are a lot of “non-open source” products that happily use ODF, without any twist of business model. I am sure IBM, Google can name quite a few.

So, does ODF support open-source, just by that it does not allow Microsoft to lock-in their users?

“IBM have asked governments to have an open source exclusive purchasing policy,” Tsilas said. What no proofs?

There are, in turn statistical information that many pro-OOXML votes in September have been from corrupt countries.
Corrupt countries were more likely to support the OOXML. So Microsoft uses dirty tactics and then they come out accusing others of it! Now how’s that?

So they they tried every possible trick and now they have come out empty handed.
The trickster has played foul and got defeated. Now they admit it and try to put the blame on people that showed their flaws and ill-doings. Or maybe they admit defeat just as another trick. Who knows, we have to wait and see!

Cheers to ODF interoperability fighters!

1. Many people realize that there will eventually be one standard, and only one standard. Of course, that standard will not be the exact same as either contender now, but it’ll probably be a newer version of one of them. Effectively, whether an official harmonization happens or not, the functionality will be represented in that standard, thus there will be harmonization.

2. Harmonization is the logical step. Having two standards is silly. Since we aren’t silly people (I’m not so sure about that), we will, of course, harmonize.

3. We want to make harmonization impossible, because if the standards are harmonized, our product is dead.

4. Various people are making harmonization impossible.

Personally, my thought is, given the stance of the Microsoft crowd on this matter, I think the OASIS should start working on the harmonizing process now. If Microsoft actually wanted to help them, I’m sure Microsoft could provide invaluable assistance. However, judging my their track record, Microsoft won’t. If Microsoft even gets involved, their actual involvement will not help the process – for a universal, open standard for documents ends life as Microsoft currently knows it. The fact that the company could survive it and even continue to dominate the marketplace even in the face of it doesn’t register with these people. As a result, they will continue fighting the inevitable and doom their company to annihilation. (Yes, my prediction is in 15 years, Microsoft will not exist as a software company, and it will be due to their current efforts to maintain their illicit monopoly.)

Actual developers who sit down and try to work with both formats encounter that ODF is better designed and more feature rich than OOXML. With ODF you have a tree that you can transform with regular XML technology and manipulate without to much difficulty. OOXML on the hand give you a chain of chunks that are wrapped in XML. Oooxml is with others words flat and transformation into anything at all require that you reimplement the full parsing capability office including all weird legacy quirks. Microsofts translator project among much similar are actual proof of this.

The other picture presented on the net are the one coming from Microsoft PR people. These people keep insisting that ODF lacks capabilities needed by Microsoft office. Unfortuneatly they never tell what capabilities that are missing or give any evidence.

It is great the Oasis offer to bring order to this mess. Microsoft have lost much valuable time and will without doubt need assistance when the market demand for using ODF keep climbing.

rob, i was quoting a Doug Mahugh post, when he talked about how he phoned a couple of “friends” to share a couple of beers ;-) and by the way vote “yes” at Incits/V1 voting

when i saw this Mahugh’s post i was scared. My god, this is the way that standardization works?!!

If that is the case, then i don’t want more ECMAs , ISOs and the like, they worth nothing to me, to end users and consumers… they are just corporations proxies ( i want technically and well engineered computer standards, i’m a system analyst , i don’t want to see my profession bastardized )

–orlando

@Chris, is harmonization complex? Yes. But however complex harmonization is, translation between divergent formats, on an ongoing basis, from now until eternity, will be far harder and far more expensive. The easiest time to solve this problem is now. Waiting only makes the problem harder.

The way you solve office productivity on cell phones, etc., is via defined and standardized functional subsets which we call application profiles. We would need to define those.

@anonymous, You are misinformed. ODF does not represent tables in a word processor as an embedded spreadsheet. We do have a single table model,but that is a virtue, not a fault.

@orlando, What makes you think there is no smoking gun? Just because I haven’t blogged about it…yet?

@Gray, With that attitude we would never have had any harmonized standards like SQL or C++. Your argument can be used to forestall any progress in any standards domain. On the other hand, you’ve clearly been quoted in the press as agreeing with me, so this is clearly not a technical hurdle for Microsoft, but only a lack of sufficient motivation. Let’s work on the motivation part.

@skc, Same answer as the first anonymous. It appears that JTC1 NB’s attempted this, but Microsoft refused to add to OOXML the very ODF features that their own translator projected identified as missing in OOXML.

@Sam, It depends on how you harmonize. If you attempt to simply mergeat the standards text, or the markup level, then I’d agree, that will be a mess.I wouldn’t suggest that. But bump it up a level and harmonize at the requirements level. And remember, doing this once and achieving a harmonized standard saves us decades of document conversions and the resulting fidelity losses. So it is a worthwhile investment by my estimation.

@jamie, I agree with you on the deprecated legacy features. Most of this work should be done by the application that actually reads the legacy binary formats and writes out OOXML,e.g., Office 2007. It should be doing a full conversion there, not a lazy partial upgrade.

@anonymous, when an adjudicated monopolist, with 95%+ market share, whines and complains about competition and their inability to have “business as usual”, then it is good to breath deeply and smell the irony.

Okay, so it’s not dead yet, but if they’re pushed to complain like this, it makes me feel better about the odds. The more pressure they’re under, the more they’ll slip up and the more pressure that will create, after all.

OOXML is a brand new standard so nothing should be deprecated.

Microsoft keeps adding features to MS Office in order to entice people to upgrade. So newer versions of MS Office must be improvements on older versions.

I don’t see why a feature in an older format can’t be converted into the new format without having to retain legacy information.

How many documents would actually be affected by a word on a page shifting left or right a few pixels? Or having a word move to the next page? The document should still be readable.

I remember (circa 1990) when a document formatted for one printer caused the document to reformat when changing to a different printer due to the different fonts and margins available on different printers. Is this still the case? Probably. With downloadable fonts this alleviates the font problem but some printers can print closer to the margin than others.

What about changing the paper size (A4 vs US Letter)?

Minor changes shouldn’t affect the content too much to render the document unusable.

When OOXML 2.0 comes out then features from 1.0 can be deprecated.

Having one format: good. Harmonization: laughingly complex.