My new role in Office interoperability

Brian Jones mentioned on his blog yesterday that he’s going to be pretty focused on Office 14 going forward and people should look over here on my blog for information about Office’s approach to interoperability and file formats going forward. I’d like to add a few more details regarding my own plans.

Over the next few weeks, I'll be transitioning to a PM position on our Office interoperability team, and I'm going to get much more involved in a variety of standards groups and activities including Ecma TC45 and the OASIS ODF TC, as well as INCITS V1 (the US SC34 mirror, where I've been an active member since January 2007).

Here's an overview of what I'll be doing:

  • Through Ecma TC45, I'll be involved in Ecma's ongoing role in SC34's maintenance of the IS29500 spec.

  • As implementers of ODF, we're getting involved in the ODF TC to stay on top of the latest changes to ODF and to help improve interoperability. I'll be our representative in that group, which I joined three weeks ago.

  • I'll continue to be active in INCITS V1, where I'm looking forward to learning more about topic maps and other emerging standards.

  • I'll be working with my colleagues to put on interop workshops and related events, to help developers create solutions that interoperate with Office and related Microsoft products.

  • Here on my blog, Open XML will continue to be a major focus, but I'll also be covering our work with ODF, XPS, the binary formats, and related technologies.

It's exciting to be part of Office's commitment to interoperability, and I'm looking forward to working with the people I've met through the IS29500 process and many other interesting people I'll be meeting as we move forward. There are so many smart and passionate members of the standards groups I'm getting involved with, and we also have many smart and passionate people working on future versions of Office here at Microsoft. It’s an exciting time to be part of this great work.

Comments (11)
  1. Nevaar says:

    re: "Office’s commitment to interoperability,"

    ROFL..  hahahahaa..  ow, my side…  quit it already! Yer killin me here…

  2. Gil Bates says:

    Ooooh-KAY…  interoperability…  with Office… right…

    You guys and your innovation are a riot!

  3. amber lux says:

    Does this mean that Microsoft Office 14 will be compatible with Microsoft Office 14?

    Or will "compatibility" continue to be defined as: "The document will open and look more or less the same, only when opened on the exact same computer with the exact same hardware and exact same software, a second time."

  4. eduardo says:

    My understanding is that there is a war going on within Microsoft these days between those who are pushing true openess and interoperability (John Carrol seems to be in this group) and those who want to hang on to the old closed, proprietary lock-in strategy. I am hoping the former group wins.

  5. Doug Mahugh says:

    I wouldn’t call it a war, Eduardo.  I’ve said many times that the wide variety of perspectives within Microsoft is one of the main appeals of working here, and we’re just as diverse and vocal on interoperability as we are on any other technology topic.

    A recurring source of amusement among the people I know at Microsoft is the perception from some quarters that we all speak with one voice.  People even write things like "Microsoft  believes" or "Microsoft thinks," as if we’re all controlled my one master brain.  That sort of thing can be pretty funny to read when you’ve just walked out of a long meeting full of vigorous debate and dissent.

    On the topics of openness and interoperability, I’m hoping for the same outcome you are, and I see positive signs every day that we’re headed in that direction.

    Amber, your view of visual fidelity as the fundamental measure of interoperability is interesting.  Do you feel visual fidelity matters more than conformance to standards?  Suppose, for example, that a standard doesn’t define application behavior or layout details, as nearly every document format standard doesn’t — does that mean that some particular implementation should be seen as the "gold standard" for rendering the format, and all other implementations should strive to mimic that application’s rendering even if those details are not defined in the standard itself?

    For example, consider tab stops in ODF.  Outside the context of a table of contents, the spec doesn’t say whether tab stops are relative to the margin or relative to the paragraph indentation.  So if a particular implementation chooses to do them relative to the paragraph indentation, should all implementations do that, to assure visual fidelity across them?

    There are no easy or obvious answers to these types of questions, of course.  We all need to work together and find ways to resolve them, by participating in the maintenance of the standards we support and by reaching consensus on where document formats end and application behavior begins.  That’s what we’re doing, and it’s what many other big vendors are doing too.

    And when I talk about a commitment to interoperability, that’s exactly what I’m talking about: working together on the thousands of little details like this that affect document interoperability.

  6. al says:

    I think Amber was referring to the uncanny ability of past versions of Word to change the page layout of a document when saving then reopening it on the same machine, let alone a different machine with a different printer driver.

    I hope to see actions matching the rhetoric on openness and interoperability, but until I see it happen I will remain skeptical. It has all been promised before, only for the the words to be redefined. Perhaps that too is a function of the many voices, but from the outside it makes the corporate entity seem duplicitous.

  7. ValentineS says:

    Its good to hear that you will be participating in these groups on behalf of Microsoft.  One thing though (my ignorance showing), do these committees review more than technology standards, and if they do, will you be participating in those "other" standards debates?  I do remember reading about standards committees in general, that they like members to fully participate in the groups activities, not just standards that are of interest to the person/their organization.

    Also, I know it has already been posted somewhere else, but could you refresh my memory, has anyone commented as to why the current version of MS Office will not be supporting ODF, when a commitment for future versions to do so has been made?  If anything, could you provide links to that discussion?  It would be greatly appreciated.



  8. Doug Mahugh says:

    Al, I’d look at it this way: are Microsoft’s products more interoperable this year than last year?  More interoperable last year than the year before?  I think the answer to those is clearly yes.  From my perspective in the Office group, things like our support for ODF, the high-quality protocol documentation, and the fact Office’s default formats are documented international standards would have been unthinkable a few years ago, and we’re steadily making progress on these and other fronts.  I understand your skepticism, and we probably earned it, but I hope we can earn your trust through these types of actions going forward.

    ValentineS, we’re participating in a wide variety of standards groups these days: I’m participating in various document-format groups, and I have colleagues who are participating in groups working on web services, programming languages, database technologies, and other technologies.  I can’t speak for others (although I believe they’re doing the same), but I’m participating in all activities within the groups I’ve joined, including those that don’t directly affect our interests.

    Regarding support for ODF in the current version of Office, to paraphrase a former US President, it depends on what the meaning of “current” is.  The currently available version of Office 2007 supports ODF via the SourceForge translator project, and the next service pack, SP2, will include built-in support for ODF.  For some information on the planned ODF support in SP2, see these blog posts:

    My post about some of the technical details:

    Gray Knowlton’s post about the thinking behind our support of ODF:

  9. The OASIS OpenDocument specification refers back to the definition of text:relative-tab-stop-position in every instance, and only just happens to define the parameters for that entry under the Table of Contents, by my reading.  Every other instance where text:relative-tab-stop-position is valid, it refers you back to the definition under 7.4.1, which, yes, is under Table of Contents.  

    That doesn’t mean the document only defines it in the context of a table of contents, but that to avoid duplication in the document, it refers you back to the first place where it’s valid, wherein they explained what the thing meant in the first place.

    I’m sorry, but I can’t help but think your example is either ignorance of the document (which a layperson willing to read the thing for the very first time was able to figure out, simply by doing a ctrl-F and finding "tab stop" over and over), or willful obfuscation of the issue to present doubt about the ODF standard.

    For what it’s worth, here’s what that standard says:

    Relative Tab-Stop Position

    The text:relative-tab-stop-position attribute determines whether the position of tab stops is relative to the left margin or to the left indent as determined by the paragraph style. This is useful for copying the same entry configuration for all outline levels because with relative tab stop positions the tabs do not need to be adjusted to the respective paragraph format.

    <define name="text-table-of-content-source-attlist" combine="interleave">


    <attribute name="text:relative-tab-stop-position">

    <ref name="boolean"/>




    Yes, it’s used within a table of content definition, but it could be as easily used within any of the other parts of the document wherein it refers you back to that example.

    In case you need a copy of the OASIS Open Document format, it’s right here: .  Fair warning, you’ll need something that can open ODTs, such as OpenOffice, KOffice, or the Sun ODF plugin for MS Office.

  10. Doug Mahugh says:

    Thanks for the detailed information, Jason.  I used that specific tab-stop example because it’s included in a DIN report quoted in an SC34 document that I received yesterday through my membership in INCITS V1.  The same document is available publicly here:  As it says in Section 2.2, Representation vs. interpretation:

    The problem here is that OpenDocument does not specify whether the tab-stop position is relative to the margin or relative to the paragraph indent. (Please note that OpenDocument differentiates between tab-stops relative to margin or paragraph indent in the table of contents – but is silent about general tab stops. Also note that e.g. Writer treats style:position to be relative to the paragraph indent.).  These kinds of “unspecified behavior” make a precise mapping definition hard.

    Based on your description, it sounds like this  report may be incorrect?  If so, that’s an unfortunate example, but my basic premise still stands.  There are numerous rendering/layout details that are not specified in common document formats, including ODF and Open XML, and these unspecified details result in different visual representations in different implementations.  This is why the ODF spec itself has different page counts in different applications, for example.

    This topic is worth exploring in some depth, so I’ll put together a specific set of examples for a follow-up blog post.

  11. eduardo says:

    Doug, I don’t care if you call it a vigorous dispute instead of a war, we seem to be pretty much agreed on what is going on in Microsoft. The point I would add is that the openess side seems to be a lot stronger than it was even a couple of years ago.

Comments are closed.

Skip to main content