The Microsoft-Clever Age-Novell ("MCAN") ODF Translator v1.0 is out of the gates at Sourceforge and it's no Ferrari.
FULL DISCLOSURE: I am with the OpenDocument Foundation and we have the ODF Plugin for MS Office which is the real vendor-neutral solution to document interop...etc. blah blah.
There will be no anxious arm-waving or droll, facetious word-smithery here because the MCAN Translator is so bad that the market will just move on.
Here's why.
Holding the performance aside (which, itself, is a disqualifier...see the burried List of Unsupported Features the length of my arm), the Translator makes it so difficult for MS Office users to create ODF files, that no one will ever use it.
Microsoft, Clever Age and Novell are telling you that it is just the first version and it will improve, but I'm sorry to say Clever Age hit the technical wall in the first month and they'll never climb over it.
For background, see my "Pretending Interoperability" [or the one with the bad language removed "Pretending Interoperability (PG Version)"] article from late October 2006 to understand how we discussed then the poor technical approach sought by Clever Age in light of the non-standard XML implementation of the Micrsoft Office Open XML formats.
The abridged version of the story is that XSLT methods for transforming from one dialect of W3C-conforming XML to another dialect of W3C-conforming XML will always work. It is definitional. If it does not work, then one of the "W3C-conforming" dialects is a punk. Well, we and Microsoft know XSLT well enough to know in advance that the design of Microsoft Office Open XML would make it impossible for this, the Clever Age approach, to work for the Translator. Let me say this clearly: Microsoft knew in advance that XSLT would provide shitty tranform from Microsoft Office Open XML to ODF and they funded the Clever Age project to use this method.
It doesn't take a genius to see the set-up. This is what Steve Ballmer meant when he said interoperability would be imperfect when he announced the basis for the Microsoft-Novell patent detente in early November 2006.
One of the
key goals of the collaboration effort is to build file format
conversion technology that will provide greater interoperability
between the OpenDocument and Open XML file formats. Novell and
Microsoft are not trying to develop a file format that is optimized to
work only with a particular version of Open Office, Ballmer said.
Nor will the collaboration team attempt to build file
converters that can make files 100 percent compatible between the two
file formats, he said. But it will achieve the level of
interoperability that customers can work with, he said.
Early Reviews
Our own conclusions from early inspection this weekend was that the C# routines take up a lot of system resources and files come out poorly in the expected 5 Trouble Spots and even in more areas where we know there should be perfect fidelity.
Fellow traveler in the blogosphere, Tim Anderson, says converter "not good."
Great news for interoperability - or is it?
In addition to requiring the .Net framework to be installed (this will be done presumably by Jeeves the English Butler, retired CIO of MI6), the procedure for saving a file with the converter is a dual-save with a .tmp extension that would confuse the members of Mensa much less the office secretary.
Double-save required. Ouch!
Moreover, the save takes 30 seconds, with the heavy C# routines chugging along in the background, and the omenous message appears, below.
Elements are dropped, indicating bad interoperability
Tim's conclusion...
So the message is: don’t even think about using this converter as a
means of standardising on Open Document while still using Word. It will
cause immense and unnecessary hassle.
Another document freedom-fighter, Walt Hucks, has a direct piece of advice...
I suggest waiting for the [OpenDocument Foundation's] da Vinci plugin to be completed and released later this year. It will allow users to natively use OpenDocument Formats, even as the default file format,
while preserving Microsoft-specific features in ODF files (and
hopefully, specific features of other applications as well, including
those which Microsoft Office does not understand or support). The ACME 376
demonstation is available now. (ACME 376 does not use ODF–it uses
another XML-based format just to demonstrate what da Vinci can
accomplish, because da Vinci uses ODF 1.2, which is slated for
introduction later this year).
Conclusion
I hope you're testing the Translator against your own organization's documents to see for yourselves how bad it is. I would also point out without the slightest touch of irony how ironic it is that you have been waiting for a document interoperability solution from Microsoft (astounding!) because it is "open source" (appalling!).
Open source is great because you get it free and someone else does the work. Well, as my wife says (she's from the mountains of Pennsylvania), "I got news for ya..." -- Microsoft ain't doing your interoperability solution. They're going to delay and delay and delay and delay until they've bought the judge and the jury.
Meanwhile, ODF policies deteriorate in confusion and go the way of Massachusetts: your elected officials turn over and the ones with any common sense ditch the issue like twenty-dollar girlfriend in the lobby men's room of the Boston Ritz-Carlton.
The OpenDocument Foundation's ODF Plugin for MS Office ("da Vinci") will probably be released under an open source license under the proper conditions; but there are two reasons why we are proceeding with care...
- peer production methods are not needed (we know the few people with the knowledge & talent to execute)
- out in the open, Microsoft will kill it
Rest assured, the ODF Plugin for MS Office will be free to end users and the code will be visible and transparent (at very least) to the Friends of the OpenDocument Foundation who fund the work. (And it will be fully vetted by the best security and code people in Christendom.) At the very least, we can simulate some of the desirable characteristics of open source without commiting suicide. (Simple formula: join the Foundation, get the Plugin.) Trust either the vendor-neutral OpenDocument Foundation or trust Microsoft.
There is a strategic component here, too, you'll want to know about. Any server-side enterprise who would like to be first in the door of any & all government CIOs for a conversation on how his/her systems will connect with the Windows desktop -- at the file format level which, with XML, is the new Win32 API -- you are going to want to talk to the OpenDocument Foundation about licensing the ODF InfoSet API to put in your servers to gain you access to the CIO's chamber.
"Liberate tutemet ex inferis"
Recent Comments