CyberTech Rambler

January 21, 2008

Partial support for OOXML is not much to brag about

Filed under: Uncategorized — ctrambler @ 11:33 pm

Right now, two posts from Microsoft camp (Brian Jones and Gray Knowlton) which brag about Google and (surprise, surprise) IBM’s support for OOXML is making its round around the internet grapevine.

Did they get it right? Partly. Jones conveniently omit the fact that searching into OOXML files is simply consuming OOXML. Google had so far, not yet allow its document production part, i.e., GoogleDoc, to produce OOXML file. Knowlton also conveniently did not give reader the big picture about the article he quoted: OOXML is not supported out-of-the-box, but rather you can perform some maneuvre (and install a file) to get a IBM product to read OOXML.

For me, support means full support, i.e., both consuming and producing OOXML file.  I need roundtrip to claim support. Ditto for ODF. Any application that fails to do production when where it can is a ‘honey trap’. It is designed to ensnare users to the application. So Apple’s iWork is a honey trap. Novell’s bastardized version of supports OOXML is not, because it does both. As for those application that does not support production, I simply do not think it is right to claim support for the document format. Adobe Acrobat Reader reads PDF file fine, it can even fill in a PDF form. However, it cannot save your files, even those filled form, in PDF. As such, it does not fully support PDF.

For the pro-OOXML camp, it is sad to see that they lower themselves to defining OOXML support as anything that reads OOXML just to make the headlines. Years of MSOffice dominance means sadly, there are few office applications to support either format. A better headline will be to demostrate other applications that writes its data to OOXML then read it back from OOXML. This is one of the point I think OOXML has a much better chance to pull off compared to ODF, i.e., integration into office automation. Its custom XML approach is not good for interoperability in the long run compared to the XForm approach. For ease of use viewpoint, however, its easier to extract data if you can define the XML syntax itself, which is what custom XML offers.

IBM and Google have software components supporting OOXML that they did not tell us about? Is it a surprise? Not to me. They expects to leak them out without pro-OOXML finding out? That will be a miracle. Grudgingly, MSOffice supports ODF, abeit indirectly. To say that IBM (to a lesser extent, Google) can totally avoid OOXML is equally impossible. The only realistic question, is there obstacle to using OOXML. Does supports OOXML? Most will say no, although in reality, in reality, it does, in the form of Novell’s and the availability of the same plugin for the vanilla Therefore, the fact that IBM put obstacle, i.e., requires the administrator to do extra work, is an important factor in considering whether IBM has OOXML support.

I can argue that at least IBM throws its official support by taking responsibility for OOXML if you want it, but Microsoft decided to use a roundabout way to avoid responsibility.

I would like to repeat my disdain for partial support for either file formats. Don’t set ‘honey trap’. Either don’t support it at all, or support it fully.


1 Comment »

  1. i dream with the day that this funky Microsoft bloggers ( Brian Jones, Matusow, Magough tandem ) blog about Microsoft respecting its customers, posting this news item:

    “Microsoft supports ODF natively”

    Comment by orlando — January 22, 2008 @ 12:11 am | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: