02.02.07
Microsoft OpenXML/ODF Translator 1.0
Here is the press release, and I went over to the project page and was unimpressed – it looks like this is Win32 only, and it’s written in C#.
Novell apparently will be adding this translator to OOO, will Novell’s OOO require Mono to achieve interoperability with this C# plugin?
Of course, no Microsoft "interoperability" press release could go without the words "intellectual property", with Microsoft trotting out Novell as the example of how to interoperate with Windows properly: by paying Microsoft royalties for the privilege.
The Open XML Translator is one among many interoperability projects Microsoft has undertaken. Microsoft continues to work with others in the industry to deliver products that are interoperable by design and provide access to its technologies through avenues such as the technical collaborations with AOL LLC and Yahoo! Inc. for instant messaging interoperability, the creation of the Interoperability Vendor Alliance and the Interoperability Customer Executive Council, and the broad collaboration with Novell on virtualization, document formats and intellectual property.
Danaergeschenk, Will Robinson! Danaergeschenk!
Update: Apparently, this is the Microsoft half of the project, with Novell to provide the OOO side, so perhaps my concern over the Win32-only thing was premature.
Content is available under CC-BY-SA
Stephane Rodriguez said,
February 2, 2007 at 5:12 am
Here are interesting points,
- you probably heard that Miguel has started to voice his side of things. Unfortunately, he’s only replicating the Microsoft party line. That’s appalling.
- the CleverAge plugin has been in development since october 2005, and the infrastructure itself is taken from an old ODF plugin made by someone else whose name I don’t remember (this was reported in Groklaw last year). Despite this project got more fuel in july 2006 when Microsoft announced they would sponsor it, it remains to be said that we are in February 2007 and the plugin not only does not do anything with Excel or Powerpoint documents yet, but even Word conversion is partial :
1) It’s not full round-trip, there is a public warning by no else than the CleverAge guy on his blog. Any government mandated full round-trip scenario is thus DOA.
2) if you take the status documents (CSV files) for the one way or other way conversions, you’ll see as much as half of the items with no status, or with partial status only, i.e. not complete.
3) that list in the point above deliberately ignores important features of documents such as password-protection.
4) it uses C# because the XML is so bad that it cannot rely on XSLT transforms alone. This proves the point of anyone questioning the value of the XML markup versus binary formats.
5) It uses C# and .NET 2.0 meaning that you are required to use Microsoft own proprietary stack just to run the code. In other words, this force feeds Microsoft .NET into corporations, whether they want it or not.
In short, we have a project with a number of contributors, which has been working on it for 16 months, and it still far far away from being a plausible “interoperability” tool for Word documents alone.
The PR itself is worth a laugh…
Stephane Rodriguez said,
February 2, 2007 at 5:15 am
In point 4) above, what I mean by “the XML is so bad”, I mean Microsoft actual XML markup. I don’t imply that XML in general is bad.
Roy Schestowitz said,
February 2, 2007 at 9:43 am
The 16-month period that you mention is a very interesting one.
Have a look at this article:
The title says it all:
Open XML: Six thousand pages, one month, no chance…
Stephane Rodriguez said,
February 2, 2007 at 12:44 pm
It’s scary.
In fact, I believe Microsoft (and Novell) could have avoided the mess they are in now if they took the time to come up with a non-Microsoft implementation of said specs before it got ratified. This would have stamped the merit of the specs, albeit a posteriori.
All what Microsoft is putting in public since they shipped, and they are proud of it, is a bunch of trivial read/write scenarios which would have been possible even if no spec at all had been published. The key point being, the new MS Office file formats are using ZIP instead of OLE streams. (borrowed from ODF, and they have got all the PR credit for doing so). It’s easy to make changes by hand or with code. And that’s what lowering the barrier to entry.
That has nothing to do with a vendor able to implement 100% of features so that it meets government requirements.