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.
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.
Same here, Sam, and great write up on the brief backstory of the plugin, too. I spent last Friday testing it and returned with garbled results on all but the simplest text files: Is Microsoft’s ODF converter DOA?. I'm stunned this would be released, both so soon and in such poor shape. It's useless, but as I warned everyone in a forthcoming word processor review: even if you use Word 2007, stay away from OXML. Save your documents in .doc format at least, if not in ODF, using Compatibility Mode only.
Better, just use OpenOffice (or any programs that uses ODF) and sidestep the whole issue.
Posted by: zridling | February 06, 2007 at 07:11 PM
It's always easy to be sceptic about the technical architecture of a product, when you have no technical background an no clue about how developing the smallest software. It is even easier when you ignore the full engagement, days and nights, of the developers you criticise. And the difficulties definitely disapear when you are part of the other camp. The only thing that is fubar here, it is your post.
Posted by: gérard | February 07, 2007 at 03:25 AM
Gérard, it appears you don't understand that by Microsoft declaring the CleverAge plugin "complete" last week, they are the one who have fooled you. (I say "you" because you sound like a contributor to the project).
The rant on spending days and nights does not mean much if the goal is fundamentally flawed : DOA because technical persons knew since day one this plugin would not be able to provide 100% fidelity.
The CleverAge project started back in October 2005, got more steam since July 2006, and still only supports a subset of Word file formats in February 2007. Those are facts, not criticism. What kind of message do you think you are telling the world when 16 months after so much intense work, it appears that little has been achieved? For instance, it does nothing with Excel and Powerpoint documents.
And it does not help that the project features deliberately ignores some critical features of MS Office documents such as password-protected documents. This feature is not just "unsupported" by the translator, it's not even listed...
In fact, I'll just keep short what could be a long story. I am an independent vendor, sell related products, and have been reverse engineering this stuff for many years. The fundamental flaw in those activities is that 1) reading and writing those files in full-fidelity actually requires a higher level knowledge of what's going on, which is akin to rendering the documents you are manipulating. That unfortunately means, in this particular case, that Microsoft's implementations are the only possible way to represent in full-fidelity, strictly speaking, features of the MS Office documents. 2) we can keep it aside, but activities like this are subject to lawsuit since the covenant not to sue does not apply to the many pieces that are not defined in the ECMA 376 specs.
Posted by: Stephane Rodriguez | February 07, 2007 at 04:59 AM