Microsoft Office program manager Brian Jones, whose work has centered around the Open XML document format, now says the so-called format war with OpenDocument is officially over. The winner, he says, is both. Jones made the statement in a blog post over the weekend following the release by Novell of an Open XML translator for OpenOffice. The plug-in enables the free, open source productivity suite to open documents created in the Microsoft format, as well as saving OpenDocument files into Open XML.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-10
g2devi - You have it backwards. What segedunum is suggesting is good engineering (getting rid of special cases) and the MS approach is defeatism (adding hacks).
And yet Microsoft Office is the only product that still supports legacy documents back 16+ years.
Documents don't magically get upgraded when a new format/specification comes out. So there is always going to have to be support for legacy documents. Because there are still people cranking out documents from Windows 98, I think the last study I saw had Windows 98 still at 5% market share.
And it is great if you can mimic the functionality of an old document in the new ODF, but there are things that cannot be mimiced. So to support this you have to create an overly gernerilized specification or add special cases. Both have their draw backs, but there is less of a chance a special case is going to contain a bug. But special cases to provide bloat.
Either way OOo isn't currently ready to convert some of the more complex legacy documents to be 100% the same as they were in their original format. And I am not just talking about Microsoft Office documents.
IBM could easily release the Lotus 123, WordPerfect, and other document format specifications, but I have heard no word of them doing that for OOo. So if a big supporter of ODF doesn't do this to make it easier for OOo to convert the legacy documents to ODF, what are the chances a proponent of ODF is going to do that.
Member since:2005-07-09
> And it is great if you can mimic the functionality of
> an old document in the new ODF, but there are things
> that cannot be mimiced.
Such as....? If you add a tag "work like word processor X" without documenting what that functionality is, it doesn't magically add support. I've already stated how two problems (the Y2K bug compatibility and legacy table styles issue) could be handled with the existing ODF standard without kludges. If there are some table styles that cannot be mimicked (I don't know of any), then what's wrong with adding the functionality to ODF? After all, if that functionality was needed before, it could be needed again in some other context.
> Either way OOo isn't currently ready to convert some
> of the more complex legacy documents to be 100% the
> same as they were in their original format.
For legal documents PDF is the best solution, not DOC or OOXML or ODF. PDF will look the same no matter what platform you are on or viewer you're using (DOC doesn't look *exactly* the same in all versions of MS Word, so I don't expect OOXML to be any different), and using PDF (especially image PDF) gives you a lot more assurance that changes have not been made. But if your format must be editable, then the strategy of supporting Word 97 DOC (backed by PDF, just in case) for legacy documents and ODF for new documents would give you the best universal solution. Granted, Word 97 DOC isn't the best format out there for legacy data, but it's well supported on most platforms and since it's not a moving target, the specs for it could eventually be created so that it would be readable 1000 years from now. (i.e. the whole reason forward looking governments want to use open standards, besides the vendor lockin angle).
Member since:
2005-07-09
> 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