Today we are announcing the creation of the Open XML Translator project that will help translate between the Office Open XML formats and the OpenDocument format. We've talked a lot about the value the Open XML formats bring, and one of them of course is the ability to filter it down into other formats. While we still aren't seeing a strong demand for ODF support from our corporate or consumer customers, it's now a bit different with governments. We've had some governments request that we help build solutions so that can use ODF for certain situations, so that's why we are creating the Open XML Translator project. I think it's going to be really beneficial to a number of folks and for a number of reasons.

There has been a push in Microsoft for better interoperability and this is another great step in that direction. We already have the PDF and XPS support for Office 2007 users that unfortunately had to be separated out of the product and instead offered as a free download. There will be a menu item in the Office applications that will point people to the downloads for XPS, PDF, and now ODF. So you'll have the ability to save to and open ODF files directly within Office (just like any other format).

For me, one of the really cool parts of this project is that it will be open source and located up on SourceForge, which means everyone will have the ability to see how to leverage the open architectures of both the Office Open XML formats and ODF. We're developing the tools with the help of Clever Age (based in France) and a few other folks like Aztecsoft (based in India) and Dialogika (based in Germany). There should actually be a prototype of the first translator (for Word 2007) posted up on SourceForge later on today (http://sourceforge.net/projects/odf-converter). It's going to be made available under the BSD license, and anyone can provide feedback, submit bugs, and of course directly contribute to the project. The Word tool should be available by the end of this year, with the Excel and PPT versions following in 2007.

There are a few other key points I want to call out:

1. Choice - It's always great to offer choices to customers, and as most people are aware we already have a number of formats we've already built in Office to meet different customer scenarios. The Open XML formats that are going to be the default in Office 2007 are going to be the most important in my mind. It's the Open XML formats that allow us to build the ODF support (and will open doors to a number of other formats as well). The PDF and XPS functionality would be another example of new formats we're providing this release.
2. Great example of Open XML development - The project is going to be an open source project located up on SourceForge, so that means anyone has the opportunity to take a look and see how it's done. This should help folks see what challenges are involved mapping from Open XML into ODF, and what tradeoffs will need to be made. We had a tool for the WordprocessingML format from Word 2003 that let you transform it into HTML, but it didn't go the other way. I think this new tool will be another great example of what you can do with these formats.
3. Interoperability - We've really been focusing on this a lot in the past year. I talked last month about our push towards interoperability by design. There is now a letter from Chris Capossela called "A Foundation for the New World of Documents" that's located up on the interoperability site that I'd encourage you to check out if you're interested in learning more (http://www.microsoft.com/interop).
4. Big challenges ahead - There are definitely going to be some challenges in this project, but I think that the approach of making it an open process will really help us achieve the best results. One area I'm going to be interested to follow is how to map features that aren't specified in the ODF spec. OpenOffice has actually made the decision to extend the spec in ways that don't actually appear to be allowed (like with numbering formats), and I'm not sure if that's the right way to go. I've seen a lot of problems when moving documents from OpenOffice to KOffice for example, and I'm sure these divergences from the spec don't help out. Is the right thing to extend in the same ways OpenOffice did, or is it best to wait for OASIS to release the next version of the spec and hope that it specifies some of those missing features? Nobody wants a format that's constantly changing, so if you do decide to extend the format like OpenOffice did, what happens when ODF 2.0 comes out and it specifies that feature differently from how OpenOffice did it? What about features that aren't in ODF or in OpenOffice? Should we create new extensions ourselves or just lose that information? It's going to be fun working with everyone to figure this stuff out.

Another cool piece of this is that it will also work in older versions of Office. This is because the tools leverage the Open XML support, and we're providing free updates to previous versions of Office that allow them to read and write Open XML. It's another great benefit of leveraging the Open XML formats for the tool.

So, this should be an interesting 2nd half to the year. We have the Ecma Open XML spec progressing rapidly; Office 2007 coming closer to shipping; and now an open source project to leverage the Open XML formats for interoperability. Sounds like fun... well at least to those of us who care about file formats!

-Brian