OSNews

> It just shows how sad Novell have become when they
> release a totally incomplete OOXML translator plugin,
> and then a Microsoft employee immediately bangs on his
> blog that this is evidence that OOXML is open and
> everything is OK.

Novell might be sad these days, but that has little to do with Miguel's comments (unless you know something I don't). Miguel simply went too far down a slippery slope and, because he's used to criticism to the point that he's immunized against it, he's unable to see how far down the slope he's gone.

It's interesting contrasting his early comments with his current ones. Originally, Mono was simply a way of solving the language binding problem in GNOME (most language bindings weren't consistently complete) and he chose the ECMA spec simply to avoid reinventing the wheel. Duplicating .NET was not the purpose and specs like XAML and Winforms had too many problems to even consider. Months later, he adjusted his opinion to .NET technologies could also be implemented, but only help people port Windows apps to Linux. It's no different than WINE in that it doesn't have to be complete to be useful (even if WINE needs to play catch up with each new Windows version). A year or so later, he adjusted his opinion to .NET technologies could also be implemented, but it should allow transparent and reliable porting of people who design portable .NET apps. More than a year later, he seems to be actively supporting XAML, full .NET support, OOXML and other Microsoft technologies as being better than open technologies and ignoring the fact that even open source applications like SharpDevelop, and Paint.NET still don't run 100% on Mono even after targeted Mono improvements, and OOXML has many issues that would prevent full implementation without a lot more reverse engineering.

Anyway, just so this post isn't too far off topic, I'd like to address some other comments:

nberardi Why not that [converting the old format to the new one instead of supporting it in the format] sounds like defeatism, not good software engineering?

You have it backwards. What segedunum is suggesting is good engineering (getting rid of special cases) and the MS approach is defeatism (adding hacks).

With the ODF approach, you pay for the backwards compatibility support once during the initial conversion. If ODF is not good enough to support backwards compatibility, then it should be extended so that it is generally more useful and not just for backwards compatibility. A word processor 1000 years in the future wouldn't need to know about long extinct Word2, just ODF. But for this most part, it's not needed. For instance, to handle the date issue, there's no reason to add a "handle broken dates" feature. Simply have the exporter automatically rewrite the formulas (e.g. the expression "date1+4" would be rewritten as "convertToBrokenDate(date1)+4" and then add convertToBrokenDate to the macro that's saved with the spreadsheet). The same comment goes for MS-specific styles -- just package the style currently used up for the specific document and be done with it instead of hard-coding them forever. It's not that hard.

With the OOXML approach, every time a new legacy format is supported (e.g. there are over 1000 formats not covered by OOXML, including ODF!) you would have to extend OOXML. This means that a word processor 1000 years in the future would have to deal with supporting all previous word processor formats instead of just "pure" OOXML sans hacks. So even if the legacy hacks are fully documented (which they aren't in the case of OOXML), the OOXML approach make every generation pay the conversion costs of importing the legacy formats because the OOXML team was too lazy to just define the format correctly the first time.

Personally, I don't see the need for OOXML. If there's something that's impossible to implement in ODF, it should be added to it instead of creating a new standard. I've yet to see a single argument why this is impossible. And if OOXML is just the XML version of DOC, why not just stick with DOC for legacy support since it's almost universally supported instead of OOXML which is not and needs years before the undocumented idiosyncrasies can be reverse engineered universally?

Edited 2007-03-07 14:38