My goodness, even CNN picked up the story about Microsoft trying to retain Rick Jelliffe to update the Wikipedia articles on ODF and OOXML for them, just as the ISO process around OOXML is getting in gear. This raises complicated issues about document formats and transparency and conflict of interest; and there’s at least one elephant in the room.
Editing Wikipedia · This news noise prompted me to check out the relevant Wikipedia guidelines, on Autobiography and Conflict of Interest. I confess to never having read them previously, and now I feel bad, because I’ve edited my own entry a couple of times (contributing a picture is OK they say, but I’ve fixed some broken grammar and minor factual errors, which isn’t).
Worse, I’ve done a lot of editing on the Sun entry. In my defense, when I first went to work it was a disorganized, ungrammatical mess, and I’ve always edited while signed in, so it’s been transparent (if it were up to me, signing in would be a requirement for all editing). So I guess I’ll have to do any further contributing via the Discussion page. Which is OK, since I’ve noticed the editing standard has picked up recently on this page and my services are probably superfluous.
So if Microsoft thinks the articles on OOXML and ODF are inaccurate (haven’t read them in ages, I have no opinion) I think they should have someone smart, reasonable, open-minded, and from Microsoft go pitch in on the discussion page and have the necessary arguments and work out a compromise that gets the NPOV (“Neutral Point Of View”) nod from the community, and based on my experience, the result will be good.
But let’s ascend from the meta level to the document-format issues themselves.
ODF and OOXML · I was really impressed with the collaborative effort at Groklaw to give the OOXML ECMA document a thorough going-over. The objections document is interesting; valuable work, but I don’t think they turned up much that wasn’t already known.
Having said that, I still think OOXML is totally bogus; ECMA shouldn’t have gone near it and neither should ISO. The world does not need two ways to say “This paragraph is in 12-point Arial with 1.2em leading and ragged-right justification”. As I argued in 2005, if you want to capture MS-Office-specific semantics (not a bad thing in principle) the right way to do it is a namespaced layer on top of ODF.
The Elephant in the Room · [Disclosure: Rick Jelliffe has been a colleague and personal friend for at least fifteen years.] I’m a little irritated at Rick just at the moment; he’s been writing regularly over at his (excellent) O’Reilly blog about ODF and OOXML, and is resolutely ignoring the elephant in the room: the reasons that ODF and OOXML exist, and the motivations behind standardizing them. This is weird because Rick’s been doing publishing technology for a living for decades and knows these issues as well as anyone in the world. Rick’s opinion matters, because he is an “invited expert” (non-voting) member of ISO SC34, the committee that recently approved ODF and will soon be deciding whether to approve OOXML.
Let’s be blunt: ODF was standardized for both idealistic and commercial reasons. Both are easy to understand: Idealists want information to be as free as its creator wants to make it, long-lived, and re-usable. Commercially, ODF is a straightforward attempt to crack open the Microsoft lock on the business desktop and allow office-suite competition to start happening. Wait, that’s kind of idealistic too, if you believe in the benefits of free markets.
OOXML was standardized defensively because Microsoft was worried that the standardization of ODF might achieve its commercial goals, and Microsoft’s lock on the office-suite market is worth some eight billion dollars of monopoly profits (as in $8B on $11B of revenue; jeepers!) each fiscal year.
You might be able to conduct an cool-headed objective dialogue about the relative technical merits of these formats without considering the issues of freedom on the one hand and billions of dollars of commercial impact on the other, but I can’t.
What do you think about all this, Rick?
[Disclosure/Historical footnote: Those with long memories might suggest a parallel between Rick’s position and mine when in 1997, I was sitting on the XML Working Group and co-editing the spec, on a pro bono basis as an indie consultant. Netscape hired me to represent their interests, and when I announced this, controversy ensued. Which is a nice way of saying that Microsoft went berserk; tried unsuccessfully to get me fired as co-editor, and then launched a vicious, deeply personal extended attack in which they tried to destroy my career and took lethal action against a small struggling company because my wife worked there. It was a sideshow of a sideshow of the great campaign to bury Netscape and I’m sure the executives have forgotten; but I haven’t. Anyhow, I thought I had to point that out first before somebody else dredged it up, but I totally don’t think Rick’s status played in this story and I’m also 100% confident of his integrity.]
Contributions
· Technology (90 fragments)
· · Publishing (162 fragments)
· · · Reference (15 more)
· · XML (136 more)
· The World (151 fragments)
· · Life Online (273 more)
Comment feed for ongoing:
From: Mark (Jan 24 2007, at 21:37)
"If Microsoft thinks the articles on OOXML and ODF are inaccurate (haven’t read them in ages, I have no opinion) I think they should have someone smart, reasonable, open-minded, and from Microsoft go pitch in on the discussion page."
That is exactly what Microsoft claims they did before approaching Jelliffe: "Brooker said Microsoft had gotten nowhere in trying to flag the purported mistakes to Wikipedia's volunteer editors." I haven't untangled the complete chain of edits on the discussion page, but at a glance it doesn't seem like there's much percentage in trying to, as you suggested, "work out a compromise" with the grade school Slashdotters congregating there.
I'm agree with your initial instincts: the policy against editing your own page is silly -- so Microsoft should just make the changes themselves, explaining them on the discussion page.
[link]
From: Mike Champion (Jan 24 2007, at 22:48)
[disclaimer - I work for Microsoft, but have no firsthand knowledge of the ongoing OOXML - ODF kerfluffle]
Hi Tim,
I have to take issue with a couple of points. "OOXML was standardized defensively because Microsoft was worried that the standardization of ODF might achieve its commercial goals". While you're certainly correct about Office's importance to the profit picture, there has been a decent level of facto binary compatibility between Office and various competitors / OSS products for awhile now. I know I had few problems working back and forth between PowerPoint and Keynote, or Word and OO, back before my slide into perdition. There are lots of Save As formats supported. There was indeed a free market, and people had plenty of options, free and otherwise, yet MS Office maintained its dominance ... even on the Macintosh platform! Look at the other side of the equation: they spend $3 billion of that revenue on the product itself, addressing things that paying customers want in an office suite. It seems more likely to have been *political* challenges such as those in Massachusetts that made it obvious that the time had come to offer the Office XML specs to standards bodies.
OOXML wouldn't win too many debates on its elegance, XMLical correctness, or emacs-friendliness, to be sure. It does succeed AFAIK at the very technical goal of making the billions of documents produced by the last few versions of MS Office representable with full fidelity in its XML format. That's a very different goal than other standard XML document formats such as XHTML, DocBook, and ODF address. Microsoft's position is that all these needs are worth supporting with international standards, and none fully replace another. Reasonable people can disagree whether migrating to ODF or saving as OOXML is the best way for *their* organization to get information longevity, interoperability, etc., but having both as official and widely implemented standards gives them the choice.
"You might be able to conduct an cool-headed objective dialogue about the relative technical merits of these formats without considering the issues of freedom on the one hand and billions of dollars of commercial impact on the other". Uhh, how do I put this delicately: Microsoft is not the only major software company with billions of dollars in commercial impact at stake here. IBM in particular appears to have invested very heavily in technical, marketing, and lobbying efforts that are likely to have a big payoff if and only if ODF is widely adopted as *the* document standard rather than one of a handful of alternatives.
Nevertheless, many of the partisans in this debate are indeed motivated by idealism. I don't want to downplay the role that idealism plays on "your side" of this debate, but in my experience at least some of the the idealists work in Redmond. There are plenty of people on the MS side have worked hard and argued passionately to open up the Office formats over the last decade or so, first with HTML (well, more or less HTML) in Office 2000 IIRC, XML in Office 2003, and the zipped XML formats in Office 2007, long before this was an obvious political/business necessity. In short, they enabled "information to be as free as its creator wants to make it, long-lived, and re-usable" years ago, in MS Office.
Finally, on "Which is a nice way of saying that Microsoft went berserk": To be frank, I watched that episode 10 years ago with horror, and had my own issues with some Microsoft people and the rather arrogant corporate culture back in the '90s too. But things change ... I guess the perpetrators are now retired and living off their stock options proceeds. Life is unfair, but it goes on, the lawyers move in, and I'm quite sure that that kind of thing wouldn't happen today. Give MS credit for one thing: they don't hire dummies (well, maybe I'm an exception) and smart people learn from their mistakes.
[link]
From: wx (Jan 25 2007, at 03:17)
what's "lethal action" ?
[link]
From: W^L+ (Jan 25 2007, at 09:08)
@MIKE:
The reason that other products are finally starting to get close on the doc, xls, and ppt formats has nothing to do with openness in Redmond. They have had to work very hard to reverse-engineer those formats, and for complex documents, they all fail.
While there is a free market, and people have choices, in practice, these proprietary formats mean that someone who prefers WordPerfect, for example, needs to have TWO office suites, because resumes, proposals, planning documents, and nearly everything else is only properly displays in Microsoft's products.
It is the government angle that gets me. All government documents are the property of the people and held in trust for them. Requiring a particular company's software in order to view or use those documents is wrong. It is also wrong when documents stored in older formats are no longer accessible due to software upgrades, but (because of secret file formats and wrongheaded legislation like DMCA) no one else can offer the option to get to them. That, in my opinion, is the reason why ISO 26300 is so important. And since OOXML is *not* designed to enable other vendors to fully-implement it, it should not become an ISO standard, since government agencies must adhere to ISO unless there is a compelling reason.
Fortunately for Microsoft, the DaVinci plugin is coming, which will enable Microsoft office applications to comply with ISO 26300. We all understand the financial issues that prompted the push to make OOXML a standard (see Tim's comment above and http://lnxwalt.wordpress.com/2007/01/21/whose-finances-are-on-the-line/ for more on this) and ensure continued vendor lock-in. However, OOXML is not the answer.
Open standards should be mandatory for anything that governments purchase. Open standards means "anyone is free to implement this format or functionality in any product at any time without seeking permission." Anything else is not open and should not pass ISO. I suggest that Microsoft should sit down with OASIS and help implement any missing functionality in ODF/ISO 26300 under the above definition of open standard. True competition will hurt for a while, but in the end, we will all benefit.
[link]
From: joe dauz (Jan 25 2007, at 09:15)
Microsoft does not hire dummies anymore? And whos idea was ZUNE??
How noble of this MS employee to defend the 2007 open standard MS when most of us were open standard in the mid 90's.
No its not about dollars at all, its about free ideas vrs. imposed ideals.
Dauz
[link]
From: Biscuit Town Boy (Jan 25 2007, at 09:18)
Hi Tim,
I have to take issue with Mike Champion.
MSFT's proposed standard does not provide guarantees that access to sufficient MSFT proprietary technology to even implement the "standard" will be made available. To say nothing of possible patents MSFT may have in this space which would preclude anyone other than MSFT from implementing it.
In what sense can this seriously be considered a candidate for a standard?
-BTB
[link]
From: David Magda (Jan 25 2007, at 09:59)
I agree with John Gruber's comment:
http://daringfireball.net/linked/2007/january#thu-25-bray_msft
The historical comment / footnote sounds interesting. Would it be too much to ask if you gave more details?
[link]
From: Jacek (Jan 25 2007, at 12:22)
Any pointers to W3C (even Member) archives? Could be very educational.
[link]
From: Chris Adams (Jan 25 2007, at 13:58)
Mike - I have to disagree with your comments about office formats. I support a number of PC and Mac users who deal with bugs in Office on a regular basis - Word's nasty habit of randomly corrupting large files or reformatting complex documents, PowerPoint's bizarre random-image-background-recoloring or video mishandling (normal humans should never have to think about resizing a video to 101% to have it play back), etc. (I will say that the Excel is much more on the ball than everyone else - we've never had a problem like that with Excel). These are bugs which affect have affected those products for many years and at least three successive releases and countless updates.
The point is not to say that Office is bad software but rather to point out that they are extremely complicated products and the legacy binary formats cause problems even for people who use only the latest Microsoft products. The only reason we tolerate this is Office's overwhelming marketshare and the barrier to competition posed by the need to handle file formats which even by the Office developers have not been able to implemented reliably. Our users who are fortunate enough to have a choice have overwhelmingly switched to alternatives - Apple's Keynote/Pages for the Mac minority, HTML, even LaTeX, etc. - simply because it saves so much hassle and distraction. The majority cannot because they need to regularly work with Microsoft Office documents received from outsiders or required by government agencies.
This is the main reason why I'm deeply disappointed with OOXML since Microsoft deliberately avoided the opportunity to remove the legacy cruft from the document formats: this should have been a clean standard with a translator for the old format which could handle all of the gory details of legacy Office documents. Sure, there might have been cases where legacy documents wouldn't be perfectly translated but that's already the case: if a week goes by here where Word 2003 can open a document created by the same version of Word on the same computer with perfect fidelity, it'll be the first. I'd prefer to invest in the future even if that entailed a one-time increase in the same corrective work we already have to do anyway.
[link]
From: Tim (Jan 25 2007, at 14:30)
In an ideal world, there wouldn't be formatting incompatibilities. Since the SGML days (and maybe before, I used a GML language on an IBM mainframe to mark up text before I heard of SGML) we've struggled to separate presentation from content, and to mark things up that way. Has WYSIWYG editing destroyed that concept entirely? OOXML seems to be about presentation; if they wanted to impress me the exporter would build a number of styles from whatever the presentation markup is in the document, eliminate duplicates, and export those as XML-FO settings, markup the document with heading, paragraph, ordered list and the like, and assign the styles appropriately. Now _that_ would be a standard to get behind.
[link]
From: Maynard Handley (Jan 25 2007, at 17:28)
@Mike
"There has been a decent level of facto binary compatibility between Office and various competitors / OSS products for awhile now."
Come on, Mike, making this sort of ridiculous statement is the reason no-one trusts a word from MS. There isn't even a decent level of de facto binary compatibility between Office on Mac and Office on Windows. Don't believe me? Try shipping a document incorporating mathematical formulae or Chinese from one platform to the other. It's a complete crapshoot what's going to happen. In my experience I've got all three of
* total transparency
* I can read, but as soon as I try to edit everything goes to hell
* I can't even read and have blank spots or gibberish in the document.
[link]
From: Mike Champion (Jan 26 2007, at 09:36)
"Try shipping a document incorporating mathematical formulae or Chinese from one platform to the other." You're right about that kind of scenario, of course. And as other commenters mentioned, there are way too many data corruption and interop problems even if we accept that there is a "decent" level of compatibility for typical business documents. (I must admit that some of the other comments made me wonder whether my relatively painless experience with Mac - Windows document interop was typical or not, however).
But whatever the current level of pain, it's too high: That's exactly why the world needs formats like ODF and OOXML, to solve the hard interop problems that are so hard to address with binary formats. At a very minimum, the exercise that the MS Office people have gone through -- and which I freely admit they might not have gone through had they not been politically outmaneuvered by the major ODF sponsors -- has the universally beneficial effect of pulicly documenting an XML representation of the old properietary formats. (I know little of the details about which formats are licensed how; see Brian Jones and Jason Matuszow's blogs for the many disputes and details they've clarified).
My point was that I disagree with Tim that the assertion that binary format lockin is a primary reason for the success of MS Office. Hence, I don't agree that any particular outcome of all these debates will have a profound impact on MS profits. I contend, although I'm sure Tim disagrees, that an MS Office that natively supported ODF with a a state of the art import from legacy formats would be more or less as commercially successful as one that only supported OOXML. (Assuming, of course, that the ODF advocates are correct that there is little *useful* information in OOXML that can't be captured somehow in ODF). Obviously desktop office software is becoming commoditized and that will inevitably drive down the profitability of the current MS Office product configuration. Clearly the next generation of products from MS and elsewhere will rely much more on the Web, and will have to have a much better interoperability story, to be successful. XML technologies will be at the heart of all next-generation office products; this debate is simply about whether an XML format designed to directly map to the legacy MS Office formats deserves to be an ISO standard along with the existing ISO document formats that have different design points.
Another comment was "Microsoft deliberately avoided the opportunity to remove the legacy cruft from the document formats: this should have been a clean standard". My personal opinion (remember than I'm a generic XML geek, not an MS Office geek) is that if somebody tried to do that, they would end up with something that looks a lot like ODF. There's already a "clean standard" for a generic office docment format; there is not an official standard for one that (in the opinion of the people who actually dug deeply into the question, and I have not) represents all the features supported in the MS Office binary formats and can be efficiently loaded and processed without major redesign of MS Office. The latter point is why it is undeniably ugly; they found (if I recall, I definitely haven't looked into this) that short tag names, no mixed content,etc. gave them significantly better performance.
So, if you want a clean XML format that represents mainstream office document use cases, use ODF. If you want a usable XML format that handles existing Word documents with full fidelity and optimal performance in MS Office, use OOXML. If you think this fidelity/performance argument is all FUD, try it with your documents in Open Office / ODF and MS Office 2007 / OOXML and tell the world what you learn.
[link]
From: Gary Edwards (Jan 26 2007, at 16:28)
ODF can handle everything and anything Microsoft Office can throw at it. Including the legacy billions of binary documents, years of MSOffice bound business processes, and even tricky low level reaching add-ons represented by assistive technologies.
W^ was kind enough to mention the Da Vinci plugin as proof of this claim. The Da Vinci plugin isn't publicly available, nor is it a finished product. But it's real and has been presented/demonstrated to Massachusetts, California and the EU.
The problematic issue for Da Vinci isn't that of perfect conversion fidelity between Microsoft binary documents and ODF. We can do that today with all MSWord documents. Nor is there a problem with the ODF 1.0 specification in this respect.
The issue is that of interoperability with ODF 1.0 ready applications like OpenOffice. The perfect conversion fidelity issue can be handled with ODF 1.0, but the interop with other ODF ready applications really really needs ODF 1.2 metadata advances. and that's where Da Vinci currently sits.
That said, we recently made a demonstration of the powerful but lightweight Da Vinci conversion engine available. You can find and download this proof of concept demo at:
http://opendocument.foundation.googlepages.com/home
The ACME 376 Compatibility Kit is the Da Vinci plugin producing ACME 376; an XML encoding of RTF.
The ODF version of Da Vinci will not be released in the wilds, even as a proof of concept, until the ODF 1.2 work is done. The reason is simple. Da Vinci works. People will use it if it's available. But if they exchange those documents with ODF 1.0 ready applications, there will be a loss of fidelity. Worse, many ODF 1.0 applications like OpenOffice are known to randomly "drop" things the application doesn't understand. This effects the round trip or return of the document to the Da Vinci ODF MSOffice desktop. We fully believe these interop - round tripping issues will be solved by the ODF 1.2 metadata model. But that in itself is still working it's way through the OASIS ODF Metadata Sub Committee.
So instead of an ODF Da Vinci demo release to prove that ODF really can handle everything MSOffice and those billions of binaries can throw at it, we've provided the ACME 376 DA Vinci for your testing pleasure. And yes you can use it for real world stuff if you want.
Let me make one last point. Contrary to popular opinion, ODF was written to handle those billions of binary documents. In fact, this was the exact issue of first specification related vote that took place at the December 15th, 2002 first meeting of the then OASIS Open Office TC. Check it out:
http://docs.google.com/View?docid=dghfk5w9_7gc99tj&revision=_published
Okay, so members of the TC didn't want to reference compatibility with any particular proprietary application suite as part of the charter! But it's also true that the first major proposal voted int the ODF specification was the Phil Boutros <microsoft tags> otherwise known as <foreign elements>. A proposal specifically designed to insure that any binary objects, processing instructions, or proprietary dependencies that might pop up in a conversion of those billions of binary documents, could be handled by ODF. ODF 1.2 enables Da Vinci to fully describe those unspecified binary objects, and set them up so that other ODf 1.2 ready applications can have an improved shot at rendering them.
Surprisingly, we don't need any Ecma 376 eXtensions to do this. We do however need the ODF 1.2 metadata flexibility and description power. It's not the conversion fidelity that's holding us back. It's interoperability with the wide range of ODF ready applications. Yes, it's an application thing, but we think we can handle a good part of this application interoperability problem at the file format level.
Hope this helps,
~ge~
[link]
From: Kevin Hutchinson (Jan 26 2007, at 20:28)
I agree with you that OOXML would have been purer as a namespace on ODF, but that's not what we have today. But surely someone can create a decent translator to convert OOXML to ODF and vice versa, or am I being naive here? Personally, I see XAML as the major interop threat out there. It now looks like the Mono project was a very cunning way to get XAML past the antitrust police. I digress...
[link]
From: Gary Edwards (Jan 26 2007, at 22:55)
Hi Kevin,
Using XSLT to perfect a transformation between OOXML and ODF is extremely difficult. This is the approach used by the Microsoft sponsored CleverAge Translator Project now at SourceForge. Reading their public blog is a treassure trove of these difficulties.
It's so difficult CleverAge has had to resort to C# routines that add structure to the OOXML presentation layer. XSLT needs highly structured files that are XPath ready. While every proposal in ODF is XSLT tested before consideration as part of the spec, the same can not be said for OOXML. Especially the presentation or styles aspects of OOXML. That seems to be where XSLT falls short.
The MS CleverAge Translator Plugin is the same application being used by Novell for the much touted and Microsoft referenced OpenOffice OOXML plugin. While they have successfully mounted the plugin in OpenOffice, both the performance and the conversion fidelity are poor.
Still, to prove that other applications have successfully implemented OOXML, Microsoft does a lot of premature shouting about the Novell work on enabling OOXML in OpenOffice. Yet it's the same MS CleverAge Translator Plugin that's having so many transformation difficulties!
The MS CleverAge C# routines running on MONO are very cool but the performance hit is way too heavy to be practical. Plus the conversion fidelity is said to be less than 60% on the ODF to OOXML conversion.
Going from OOXML to ODF however should work great. Insisting on doing the ODF to OOXML transform first is really hurting Microsoft. ODF was written to handle Micrsoft Office and the billions of binary documents bound to MSOffice. The same can't be said of OOXML. Conversions to ODF and interoperability with competing office productivity suites is the last thing on Microsoft's to do list. (Whoops, i just checked the list and those two items didn't make it. And it shows.)
Besides, Microsoft champions this thing called "interoperability by design". Which means, their applications will have great file and application interop across all desktop, server and device systems. Incredible interop. But if your file format or application wasn't in their "design objective", your sol.
Easy, universal transformation is one of the great promises of XML. People hear that a file is XML or that an application can produce or consume XML, and of course they assume "universal transformation" too. Not in this case though. In hundreds of ways known, and perhaps thousands yet to be discovered, Microsoft has broken the promise of XML. So what else is new?
~ge~
[link]
From: Paul Hoffman (Jan 27 2007, at 16:05)
Mike: I normally don't play pile-on, but your comment was so far out of reality that I feel it necessary to reply. And I have dirt-simple proof of how wrong you are.
Take a Word document that has been edited by many people over the years running different versions of Word/Win. Copy it to a Mac and edit it a bit on Word/Mac. Now take it back to the PC. There is a really good chance it looks borked. Even if it doesn't look borked, as soon as you start changing any of the style formatting, it is likely to explode.
Take the same document and keep editing it on Word/Win and none of these problems appear.
If Microsoft can't get it right within their own products, it is absurt to claim that others can do so <i>even if they had Microsoft's own internal documentation</i> which, of course, none do.
[link]
From: Simon Phipps (Jan 31 2007, at 17:21)
@Mike:
> Another comment was "Microsoft deliberately avoided the opportunity to remove the
> legacy cruft from the document formats: this should have been a clean standard". My
> personal opinion (remember than I'm a generic XML geek, not an MS Office geek) is
> that if somebody tried to do that, they would end up with something that looks a lot
> like ODF. There's already a "clean standard" for a generic office docment format;
> there is not an official standard for one that (in the opinion of the people who
> actually dug deeply into the question, and I have not) represents all the features
> supported in the MS Office binary formats and can be efficiently loaded and
> processed without major redesign of MS Office.
So let's work on that format, Mike. Bring MSFT to the OASIS ODF WG, and let's define a namespace to overlay over ODF so that all the Office compatibility works but so all the world has a baseline. That way we all win.
[link]
From: John Geering (Feb 01 2007, at 16:53)
Regarding Mike Champion's comment:
"[OOXML] does succeed AFAIK at the very technical goal of making the billions of documents produced by the last few versions of MS Office representable with full fidelity in its XML format."
How does it succeed in that?
Can Office 95 or 2000 save documents as OOXML? Surely you need to open the legacy documents in Office 2007 and then save them as OOXML - but doesn't that make them Office 2007 documents anyway - and most of them could in fact be opened in the real OO - OpenOffice - and saved as ODF.
Am I missing some here, or is all this talk of preserving the billions of legacy documents in XML a compelete croc?
[link]
From: Stuart Ellis (Feb 04 2007, at 03:38)
I think that this hits the nail on the head - Microsoft has several billion reasons to oppose genuine interoperability, and this reality probably overshadows all other concerns for them. To some extent MS decision-makers are in a difficult position, because the potential (adverse) commercial impact of accepting ODF is so high that they can't do it, regardless of the benefits to everybody outside of Microsoft. Given the issues with the current formats I'd argue that some MS products would benefit from moving to ODF as well. Right now though it may be career suicide for an MS executive to even suggest that the company should compete without the advantage of file format lockin.
My own feeling is that the only way out of the trap is for governments to go ahead and mandate ODF. MS executives can "do their duty" and protest, before getting on with competing by developing Sharepoint and other products that sit on top of the basic office suite.
[link]
From: Mike Champion (Feb 04 2007, at 12:19)
I see this thread is still alive, so a couple of replies:
Isn't there a big contradiction between the argument that " most of them [legacy Word docs] could in fact be opened in the real OO - OpenOffice - and saved as ODF" -- which is more or less my original point -- and "it may be career suicide for an MS executive to even suggest that the company should compete without the advantage of file format lockin."?
Now that the ODF plugin for Word has been released http://sourceforge.net/projects/odf-converter a lot of the assertions made in this thread can be tested empirically -- you can see how good/bad, fast/slow the conversion each way is, and you can see if Brian Jones and his management have committed career suicide by breaking the lock and opening the floodgates to OpenOffice :-)
On "Surely you need to open the legacy documents in Office 2007 and then save them as OOXML ", note in http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=941B3470-3AE9-4AEE-8F43-C6BB74CD1466 that OOXML is supported in Word 2000, 2002, and 2003 as well as 2007.
Finally, Simon Phipps suggests "Bring MSFT to the OASIS ODF WG, and let's define a namespace to overlay over ODF so that all the Office compatibility works but so all the world has a baseline. That way we all win. " For better or worse, I don't have any power or influence over the people who would make that decision. I *personally* think they should have seriously participated in the ODF TC all along; I don't think we'd have one true document format now, but we would have less of an OOXML - ODF impedance mismatch, and hopefully less bad blood. All I can suggest is that the probability of this happening in the future would be increased by toning down the rhetoric from the ODF side a bit. For example, can't we agree that "summarily silence the Microsoft opportunists, shills, boot licking lackies" https://www2.blogger.com/comment.g?blogID=11236681&postID=67184903082331117 is a bit over the top? I don't think it's helping the political battle in ISO, and I can't imagine that it promotes warm fuzzy feelings about closer cooperation with the ODF TC among MS Office folks.
Whatever happens this year at ISO, various governments, and the market, the chances are that we will end up with several partially overlapping standards (de jure and/or de facto) for documents, including XHTML, DocBook, ODF, and OOXML. The Microsoft party line, which I do personally agree with, is that this is Just Fine -- there are a manageable number of well-documented and effectively standardized formats for various purposes, nobody is locked into an application, but applications are free to compete on actual cost, user experience, performance, reliability, etc. It would be very interesting to discuss whether some subset of these formats could be usefully combined the way Simon suggests, with enhanced features layered as namespaces over a base spec. I'm not sure that will work or if many end users would care (why isn't ODF a namespace overlay on top of XHTML?) but it would definitely have some geeky coolness if it could be done. Forget MS profits, hurt feelings, egos, etc: This could come about only if a lot of people agree that the world would be so much better off with a cleanly layered format with OOXML features over ODF (over XHTML?) that the result would be worth the development and conversion cost.
[link]