I think its a healthy monopoly like W3C toe hold with HTML. People need a standard app for doing office documents. Susidizing the losers in the market is a waste of time. There winners should decide the future not the minority.

The point the other commenter tried to make about OLE is deceptive as well. If a competing product does not support ONE important feature of said Microsoft product despite all the best effort and many years of work, then this proves that competing product cannot compete on equal footing. If Microsoft had not choose to submit this stuff to ECMA and ISO claiming “it can be supported”, may be (just may be), we would not be up in arms.

At that point, I feel safe to say that someone supporting those obviously flawed Microsoft claims is either ignorant or paid by Microsoft.

-Stephane Rodriguez

Note that I loaded the same document in XLS format into Gnumeric and it rendered quite completely. So I have established that Gnumeric supports that feature set. Then I loaded the same document in XSLX format and it rendered very poorly. So this demonstrates that the OOXML support is the problem, not the application support for the underlying features.

This is nothing new. Let’s say WordProcessorA supports charts but WordProcessorB does not. Let’s say a user uses WordProcessorA to create a document containing textual data and a corresponding chart. Now another user uses WordProcessorB to edit that file. Even though WordProcessorB understands the file format, it doesn’t support charts as a feature. So what should it do? Many would say that it should just show the text, keeping the chart data in tact. But if it did this, someone like you would use that as evidence that the file format itself is not implementable by parites other than WordProcessorA. Another, more practical, problem is that if the user opened the file in WordProcessorB which displayed the textual data but kept the chart data intact, then the user edited the textual data and saved it, causing WordProcessorB to save the new textual data and the original chart data, then the document is left in an inconsistent state. When a user used WordProcessorA to open the file, he’d see that the textual data no longer matches the chart data (if he’s lucky; if he’s unlucky he wouldn’t notice the inconsistency).

ODF is not immune to this sort of thing.
The Windows version of StarOffice and OpenOffice support OLE. What happens if you open an ODF file containing an OLE object in some other ODF app on Linux? How does the app handle the OLE data? Does it display it correctly? Does it do anything to make sure that it remains consistent with changes the user might make to the document?

Putting OLE aside, how about the hypothetical example that I provided? What happens if you open an ODF file containing charts in an app that understands ODF but doesn’t support charts or graphics? How would it “display” the chart? How would the app make sure that changes made to the document remain consistent with the chart data?

If you want to do tests like you have done, you need to make sure that the apps you’re using to open a file support the features that are in that file in the first place. If they don’t support the feature, then they can’t reliably handle the data, even if they understand file format.

Recent versions of Gnumeric will give you 08/23/2007 in en_US locale, but the format to use really comes from the C library.

–Morten

One sad note from yesterday, the German DIN has accepted[1] OOXML :( – I really can’t understand that discision.

[1] http://www.din.de/cmd?cmsrubid=56731&menurubricid=56731&level=tpl-artikel&menuid=49589&bcrumblevel=1&contextid=din&cmstextid=65004&cmsareaid=49589&languageid=en

We all think of the desktop software here. But let’s not forget about the back-end. With e-discovery in the US and many governments subject to access to information laws, the document management systems are critical. Several large organizations will see these systems as key to achieve legal compliance.

Non compliance is not an option. Document management users will not use a format unless it is supported by the back-end.

Microsoft is trying very hard to own the back-end market with Sharepoint. What will these vendors do? Will they cozy up to Microsoft to make sure they have access to the information they need to integrate the newer Office file formats and keep their systems current? Or will they seek independence with ODF?

In any event they will be subject to the run and chase game while Microsoft is after their market. Microsoft, not the partner, has the power to change the rules of the game at the drop of a hat.

But it DOES take someone who doesn’t have a financial incentive to believe otherwise in the face of clear evidence. At least, that’s been my observation.

Frankly, people do NOT need new word processors / spreadsheets every few years. I couldn’t use 90% of the features in Word if I wanted to without spending hours researching just what they do, but I can still produce anything I need to just fine by using sensible formatting.

It’s funny, my aunt just retired and needed to type something up so she asked if I had Word (I haven’t built her a computer just yet). I told her no, but I had Open Office. She was fearful: “I don’t want to spend hours learning a new program!” But then I showed her it, and just how familiar it looks.

She sat in front of it and didn’t need to ask me how to work it. She was producing a document with formatting, too. Nothing fancy: just the normal things people use when they’re not trying to create garish documents, so it just used a little bold, underlines, centering, tabs, etc.

And she’s not a computer person.

It’s no wonder Microsoft hates open formats: it would KILL Word’s revenue if the 95% of people and businesses who don’t need anything fancy didn’t have to keep upgrading it to read the files other people send them.

Here are my two cents on the topic.

I just place myself in the shoes of a CIO that has to choose between ODF and OOXML. Suppose for the sake of discussion, this is just a scenario not reality, that ODF developers don’t include good OOXML support in their software and conversely OOXML developers don’t support ODF well either. Then the CIO is faced with this alternative:

1- If the CIO picks ODF, he cannot easily exchange documents with partners and customers that prefer OOXML.

2- If the CIO picks OOXML, he cannot easily exchange documents with those that prefer ODF.

What is a CIO to do in such a situation? He will ask “where the bulk of the market is going?” If he gets the wrong answer, exchanging documents with external parties on a daily basis could be a living hell. The CIO will then want to reverse his decision and join the rest of the crowd. There is also the legacy of thousands of documents in the wrong format he will have built. There will be no easy way to migrate them to the other format.

CIOs will see this alternative as a pair of lobster cages. Once he crawls into one of these, there is no easy way to get out. Therefore the CIO will want to pick the right one from the beginning.

This means CIOs have a strong incentive to stall their decision and remain with the current binary formats until the market winner is clear. This is the dominant selection criteria above cost, technical merit and openness. Those that move ahead can only use the binary formats as a lingua franca to bridge the ODF and OOXML users. This defeat the point of having a standard. Neither ODF not OOXML can benefit from this situation.

But what if the CIO faces a forced upgrade? What if the Office suite support expires and there will be no security patches anymore? The CIO will see any forced file format decision as a bet on which format is most likely to become the dominant one. It is tough to go against an established monopoly when the decision is framed this way.

The above discussion was about an hypothetical scenario where ODf software doesn’t work with OOXML and vice-versa. Let’s go back to reality.

A CIO looking at OpenOffice vs MS Office 2007 will see this alternative:

1- If he picks OpenOffice, he will be able to share ODF and receive OOXML documents without problems.

2- If he picks MS Office 2007, he will be able to share OOXML and receive some ODF documents thanks to the CleverAge converter.

There are no lobster cages. Conversion from a format to another will eventually be possible, even if the tools are rocky for now.

A- OOXML to ODF will be supported by OpenOffice.

B- ODF to OOXML will be resolved. Who expect Microsoft to keep stalling on the Office 2007 ODF support if the OOXML to ODF conversion works in OpenOffice? Users that choose ODF would have no way to go back to Microsoft but the reverse is not true. The OpenOffice user base can grow at Microsoft’s expense but the reverse is not possible. Microsoft cannot tolerate this.

Market share is no longer the dominant criterion. The CIO can now afford to look at other considerations. OpenOffice has a strong cost advantage and allow for better document exchanges with users of both formats. ODF is more open. Much of the incentives to stick with the monopoly are gone.

Because Microsoft controls the spec, Microsoft Office is the “Golden standard” of how OOXML must be implemented — even if Microsoft implemented it poorly, it is still in other vendor’s favor to follow Microsoft’s implementations.

Another point is market lead. With OOXML, Microsoft will *ALWAYS* be the first to market supporting the latest and greatest of anything to do with OOXML — and as a result Microsoft’s Office products will always be seen as the defacto standard and the market leader.

Does Ecma own Ecma 376? Yes, in a formal sense. But that ownership consists of ownership of a stack of papers. But the management of this standard is delegated to a committee chaired by Microsoft with a charter that prevents them from making changes that Microsoft does not want. Microsoft is not obliged to have TC45 meet to develop future versions of the standard collaboratively. Microsoft can do all of the work internally and then forward the completed revision to Ecma for rubber stamping. Microsoft doesn’t really give up any control.

Remember, in a previous post where I showed the Ecma slide where they claim that one of their benefits is that the “minimize risk of changes to input specs?” This can only happen when the submitter maintains sole practical control over the standard.

As for ISO ownership, Ecma has already sent JTC1 a proposal which would designate Ecma TC45 as the maintainer of OOXML. So maintenance releases of OOXML 1.0 would be owned by Ecma and proceed under their rules, which pretty much reverts to the above, where the work happens by Microsoft and is merely rubber stamped by Ecma.

Except that ECMA 376 does not reflect Office 2007 actual implementation. I’ll give just one example : VML parts. It’s important because VML is over the place in ECMA 376. ECMA 376 says it’s deprecated. Office 2007 however creates VML parts for NEW Word, Excel or Powerpoint documents (below is one example).

If you think that’s nitpicking, think again. Implementers will have to write a VML library (a lot of work, no spec except a cursory description in ECMA 376) if they want to read Office 2007 files without fidelity loss.

We know where this goes. It’s a replay of binary blobs used in binary formats. By the way, the binary blogs are still here (see my article on Codeproject).

Also, any implementer will quickly figure out that ECMA 376 was written after Office 2007 was done and it by no stretch of the imagination can be called a fidelity dump of what implementers need to do to be on equal footing with the Office 2007 team (provided they have the time to implement all what it entails in the first place).

It’s typical Microsoft fire and motion.

So Microsoft can put ECMA or ISO under control of the destiny of ECMA 376. It just does not matter since it’s a theoretical paper that does not reflect anything that exists.

Example for creating VML parts :
- create a new Excel 2007 spreadsheet
- right-click and choose Insert comment
- type a comment.
- save, close.
- unzip the XLSX file.

-Stephane Rodriguez

As Sutor says over and over, “ODF is about the future.” We’ve got the past covered with binary formats. Giving in to MS-OOXML is like paying twice the price at the gas pump — for what reason?

Isn’t that the whole point of ISO standardization for the format, taking control AWAY from Microsoft? If we don’t trust them, shouldn’t we want their format controlled by ISO instead of the people in Redmond?