Microsoft's Matusow and Mahugh on Office's move to open format support
Where Open XML and ODF differ, which one gets the advantage?
As we learned during our coverage of the ongoing effort to produce document format translators, Open XML's features and OpenDocument's do not map one-to-one with one another. In other words, you can't just have every Office feature that's represented one way in Open XML, seamlessly switched to someone else's method. Not everything gets kept in the translation.
So who loses out? One would think Microsoft Office probably would not be the first choice of some users, including some governments, that prefer ODF. Winning them over will be a hard sell.
DOUG MAHUGH, program manager for ISO 29500-based products, Microsoft: One thing to be very clear about here is this: When we say, "support for ODF in [Office] SP2," we intend to write very compliant ODF documents when you save a document. However, it's not a given that everything you can do in the Office UI is savable under ODF. As you're alluding to, there are things -- SmartArt, conditional formatting, things like that -- that we have in Office and that are popular features, where there is no way to save those in ODF, currently.
The way we're approaching that, I can share a little bit with you: We're not throttling the UI, as you describe, where certain things are disabled. Rather, at the time you save, we're telling you, "Hey, you're saving in this other format; some information in this document may be lost." That sort of thing. And let me tell you why we made the decision to do it in that particular way: There are situations where some of that functionality may be very useful to the user, even though it can't be serialized out to the format that they're saving in.
For example, I could e-mail you an ODF spreadsheet, and you might have Excel 2007 and want to open that spreadsheet and do some quick thumbnail analysis of a few things, use conditional formatting to help you identify some trends quickly, and so on. We want to let you do that, even though you can't then save that conditional formatting back out to ODF. So for that reason, we've tried to look at it as, these issues we're talking about, functionality that may or may not be included, those are issues when you save the document, but we're not letting those factors affect the overall user experience, or the sorts of analytical tools that you might have at your disposal.
But how can Microsoft go forward developing features for Office without simultaneously, and perhaps even irreversibly, creating new features that must be entered into at least one document format it supports at some time?
JASON MATUSOW, Director of Corporate Standards, Microsoft: I think one of the biggest things to keep in mind whenever you're considering the document format discussion, is that document formats are the representation of the innovations that are happening in the applications space. The engineering decisions that were made in the original creation of ODF represent the engineering pathway and the innovations that were happening in the OpenOffice space. The engineering decisions and development pathway for Open XML represents that which was happening in [Microsoft] Office, and the feature sets are not in parity. In fact, there's a superset of features within the Microsoft Office set, but there are certainly features that are exclusive to OpenOffice that do not get covered in Microsoft Office.
It's like this: If I'm speaking German to you and you're speaking English, and you say to me, "Well, there's more than one way to skin a cat," there is no direct relationship between what you were intending to say in that idiom, and what I in German would hear in the translation of that.
To the extent that there's business competition that OpenOffice and Office and Corel's products and Adobe's products and IBM's products around Symphony or Google Docs or whatever, to the extent that product competition exists, there will always be that challenge of [how applications render formats versus how specifications interpret formats]. I think that will be an ongoing part of the discussion.
The reason that it's so important that we go and join the OASIS ODF Working Group and the PDF Working Group in AIIM and the ongoing work in JTC 1 and the work that's happening in ECMA, etc., is that these issues start to bubble up and become consistent discussions. We really hope to see ODF move to JTC 1 / SC 34 maintenance; and the ongoing work that started in DIN, the German national body, around translation and interoperability, also is progressing. It's currently under letter ballot, we're moving to SC 34 as well. All of these things are critical in having the engineers who are building these products be able to get together in a constructive environment and start to hammer out these issues, because there are inconsistencies.
Those aren't bad things; those are actually representative of the fact that you have innovation in play, and competition in the marketplace. All of those factors contribute to it, but there are definitely engineering tradeoffs that have to be discussed.
Next: Allowing just anyone to make Office's next big format