Open XML SDK roadmap

Open XML SDK roadmap: timeline

After nine months of developer feedback on the Open XML SDK, we have some good news today: a roadmap for releasing the API. We have two versions coming: a version 1.0 that will be released in May, and then a version 2.0 that will be available as a CTP this summer, and will be released around the time of the next major release of Office (Office "14").

The details are covered over on OpenXMLDeveloper, and you can learn more from these links as well:

for those who aren't familiar with the SDK, this is an API for the .NET developer crowd that is designed to really increase productivity for developers building Open XML solutions. We have the Packaging API in the .NET 3.0 framework, but that's a lower-level tool than some developers want to work with. So the Open XML SDK provides "strongly typed parts" capability, which means you can get to the parts within the package quickly and easily. For example, you'll see code like this:

 using (WordprocessingDocument wordDoc = WordprocessingDocument.Open(filename, true))
                MainDocumentPart mainPart = wordDoc.MainDocumentPart;
                CommentsPart commentsPart = mainPart.CommentsPart;
                XDocument cDoc = commentsPart.LoadXDocument();

The net effect of working with the SDK, relative to working with the packaging API, is that the size of your code goes down and its readability goes up. It's hard to generalize on code-size metrics, but I've talked to developers who have experienced code-size reductions of around 50% on large projects.

Developer Perspectives

One class of developers we see moving to the SDK is developers who have written their own libraries for Open XML development in the past and now want to move to a tool that they won't have to maintain on their own. For example, Datawatch implemented Open XML support in Monarch v9 early last year, and at that time they worked from the ECMA-376 spec and wrote their own tools for handling parts within the package.

But as Senior Product Manager Gareth Horton explains, "The introduction of the Open XML SDK has given us the opportunity to replace some of our own code responsible for reading and writing Open XML, leading to a smaller codebase to support internally. Not only does this give us the ability to focus more on our core competencies, but it will help to reduce the amount of coding to account for specification changes made as a result of the recent ISO BRM." Datawatch implemented the SDK in just one week, which also provides a good example of the developer productivity it offers.

Another Microsoft partner I've talked to quite a bit about the SDK is Stephen Peront, CTO of Xinnovation. Stephen has been an active and vocal provider of specific feedback on the SDK (he's not a shy guy :-)), and many of the upcoming changes (described here) are based on creative ideas from Stephen and other developers who worked with the first release of the CTP.

The team at Xinnovation was doing Open XML development work over two years ago, and as Stephen explains "we are already ahead of the curve developing and implementing real-world OOXML solutions in Financial Services and Life Science with clients such as Fidelity Investments and Pfizer ... the release of the Open XML SDK means great things for Xinnovation, our clients and the global community; anyone who is building document solutions should take a look at what this standard and SDK can do for them.”

Thanks for all your help getting here, Stephen, and please keep those great ideas coming!

Press Perspectives

In addition to the developers using the SDK, I've had the pleasure of talking to a few writers and reporters about the SDK this week. I noticed a few of them have posted articles already, so here are a few to check out for additional perspective on the announcement:

Compliant with the final ISO/IEC spec? Yes, from version 1.0

There's one final detail about the SDK I'd like to clarify, which relates to Gareth Horton's point above about the spec changes accepted at the BRM. When I talked to reporters earlier in the week I wasn't certain about whether we'd have all the final ISO changes in version 1.0 of the SDK, and I was careful to not represent that we would.

Well, I seem to have underestimated our dev team: I've now verified that version 1.0 will definitely be 100% compliant with the final ISO/IEC 29500 spec, including the changes accepted at the BRM. So starting in April you'll be able to build applications that are compliant with the final spec, and in May when we release version 1.0 you'll be able to go live and ship products built on the API. Time to get coding!