I should also note that the JTC1 prohibition against contradictory standards did not exist 10-15 years ago when these conflicting image standards came about. The contradiction clause in the JTC1 Directives is a relatively recent addition. So one can assume that it was added to curb the abuses of the past. So presenting examples of contradictory standards before then does not really make a strong argument.

So back to OOXML. It was submitted to ISO only 3-months after ISO’s publication of ODF. This is hardly the timescale where one can argue that ODF was superseded by newer technology. Also it is clear that OOXML is attempting to serve the same market niche as ODF — Personal Productivity Application. No one can argue that Microsoft Office and Open Office are in different markets.

If two different image formats which represent almost exactly identical subject matter can exist as non-contradictory standards, why cannot two different office document formats that encompass significantly different object models do the same?

Any conversion requires some human verification to see that it worked correctly. I’ll suggest a criterion for all: when translation technology is so perfect that you would be willing to run your resume through it, and send out the resulting document, as-is, without looking at it first, then translation software is good enough to run without a manual check, and even then only for documents as simple as a resume.

Compare this to image conversions, where it is expected to be 100% flawless. This is because image formats (TIFF/GIF/JPG/PNG) represent nearly the same thing. They are really just different encodings of a rectangular grid of pixels, with different colors, along with some metadata specifying transparency, color space, compression, etc. But the core of it is just a grid of pixels, a bitmap. The abstract model expressed by a document format is several thousand times more complex than this.

- A server that convert documents received by mail into PDF and mail back the result to the user.

- A Terminal server running Microsoft Office for users that have a one-time or short term need to edit OOXML documents sent by third parties.

During initial implementation, the service bureau will act as a task force to convert large repositories where there is a business reason to convert.

Afterwards, conversion will be an on-going activity because outside correspondents might not migrate to ODF right away and insist on OOXML. This situation will persist until the market perception that document standards must come from Microsoft wears out.

The service bureau staff requirement will be reduced past the initial implementation, but some service will need to be maintained. Once ODF becomes dominant, the service bureau can be totally discontinued.

A note for those that believe too much in automated tools. They are good but only to a point. Software has bugs. Converted documents need to be checked for fidelity. Inventories need to be validated for accuracy. This is a project cost in the cycle of inventory, convert and validate. This cost is a function of volume. Any strategy that reduces the volume reduces costs. Also documents have retention limits past which they can be destroyed. In many cases if the retention limit is shorter than the viability of keeping the ability to read and convert on-demand legacy stuff, there is no immediate business needs to convert.

I did notice one or two slight look changes in the spreadsheets.

We might consider it as a valid method for conversion in a year or more. Allthough we do not expect the old MS Office formats to cause any problems for 5-10 years at least. We did actually found it reduced storage capacity with almost 27%. That would save us 100k-200k in expenses a year (storage,+ backup + servers) not including possible netwerk/email server savings. We should test more as the savings could be due to the nature of the converted documents in the tested set.

Allthough we consider ODF a fine alternative we have not considered it as an option (yet) as we consider the prime choice is between Office products and not between Office formats.

I don’t think many people look at conversion as a space saver but it might wel be worth checking out if you have millions of documents.

The difficulty of doing so is not really a good argument: not only does MS made import/export converters for older versions of Office available, but it provides tools* that make inventorying and bulk conversion relatively trouble-free. Seriously, what could they have done to make it any easier?

By not upgrading now, one is simply passing on costs to the future. It’s akin to deferring maintenance–generally not a wise idea.

Admittedly, there may be some intricate documents that break upon conversion. But that’s why, before converting, you archive all your documents. Then, if something goes amiss, you always have the option of restoring the original file.

* See: technet2.microsoft.com/Office/en-us/ library/d0373697-31f5-4fc5-8dd1-1b9d7f35842f1033.mspx

Conversion costs apply regardless you go ODF or OOXML. This is important because the Microsoft compatibility talk implies that ODF requires costly conversions while OOXML does not. This perception is wrong.

We don’t need to convert most legacy documents. Among those that need conversion, most are kept for archival purpose and can be converted to PDF because they will never be edited. What is left?

The conversion to ODF is required for stuff like templates and application front-ends. Should one choose OOXML, these same documents and applications also need to be converted. You don’t want to keep generating legacy stuff forever.

Whatever format one choose, there is a need to inventory, convert and test. The difference in costs will occur only if OOXML somehow makes faster/better automatic conversion than ODF. How does that compare to licensing or hardware upgrades for Office 2007? Compatibility issues are overblown.

For me, I will convert my personal writings (short stories, theses, dissertation) to ODF, but since StarOffice/OpenOffice reads my legacy .doc files with such accuracy, your guidelines will save me a year of conversion time.

No big conversion orgy is required. Over 95% of the documents need only to be read. This does not call for a massive conversion. What needs conversion is two things:

- The templates, especially those with plenty of macros. These are the ones that need to be used on a daily basis to produce new documents and feed corporate workflows. You want the new documents to be in the new format.

- The applications, those that use Excel as a reporting or data entry tool, the systems indexing official versions of documents. You want to adapt them to use the new format.

Almost everything else can be left out of scope for the migration project. Most documents are kept only for archival value. Users can be trained to convert the document they need to have handy in the new format. Selecting these document is a business decision that is best left to their owner. The conversion itself can be performed on an as needed basis. No need to gather a big inventory and anguish about getting the classification right. Users will convert only what they need. After a while most documents will become obsolete and there will be no point converting them anymore.

If there are difficult cases that can’t be read with the new office suite, a server can be configured to automatically convert anything sent to it into PDF. This server can be left available for years until there is very few legacy documents still relevant.

Stuff that needs to be retained on a very long duration for legal reasons can be batch processed into PDF upfront if keeping them in legacy format is not good enough. Users can point out where repositories of such documents are stored. If there is a legal reason to keep them, they should be indexed and kept in a well defined place anyway. If they are not, then you have grounds for a project having nothing to do with the choice of the next file format or office suite.

For read only compatibility, PDF is more than good enough. I find the later point ironic since Microsoft advertise read and convert compatibility as the main justification of OOXML without noting that PDF already does about everything that needs to be done. We don’t want to retroactively edit our archives.

If there is anything left that still can’t be handled, then there is an administrative procedure called derogation. You give some individual that have unusual requirements some unusual rights to deviate from the corporate standard and use a second Office suite on top of the main one. He knows he is an exception and will jump through the required hoops to interface with the rest of the corporation. After a while the annoyance will make him find ways to bring himself back into the corporate standard.

In my opinion, massive legacy document conversion is a red herring.

A more serious issue is what you do with correspondents and business partners that insist on using a different file format. The perception that Microsoft defines the standard due to market share works like a self-fulfilling prophecy. There are people that will be reluctant to adopt ODF by fear of being unable to exchange with the masses that will use OOXML. But if everybody thinks the same, there is no real reason to stick with Microsoft, just some irrational group behavior.

On the other hand, I guess it’s a balance of costs: certain high cost to do all conversions now, versus a low probability of a high cost to do a small number of conversions much later.