|19 Nov 2009||#1|
| || |
Open XML: One Year In
As you’ve probably heard, this is a big week for Microsoft’s Business Division. Earlier this week we announced the public availability of Microsoft Office 2010 Beta. Have you ever wanted to co-author a document with your team in Word? Have you ever wanted to analyze tons of data at once in Excel? Have you ever wanted to push the limits of multimedia in your PowerPoint presentations? If so, check out the Beta.
It’s also a big week for the standards community, especially for those of us working in document formats. This week marks the year anniversary of the first publication of ISO/IEC 29500, also known as Open XML. As the cross-Office driver responsible for Open XML support in Office 2010, I thought that now would be a good time to reflect on the work that we have done in Office 2010 to support the Open XML standard, as well as how improving interoperability relates to our ability to innovate in Office.
Open XML Support in Office 2010
In the document format space, the big question on everyone’s mind is what level of support Office 2010 will have for Open XML. I’m happy to announce that Office 2010 will generate, by default, ISO/IEC 29500-compliant files of the transitional conformance class.
The first step to get Office 2010 generating ISO/IEC 29500-compliant files was to evaluate the files that we were generating in Office 2007. That product was generating ECMA-376 First Edition files, which, as you’ll recall, was the precursor to the ISO/IEC 29500 standard. Once we identified the differences in syntax resulting from either bugs or changes in the standard, we went about making the changes required to get our syntax compliant.
It generally surprises people when they learn about some of the changes we had to make to get our syntax compliant. In most cases, the changes were due to trivial bugs in specific scenarios. A favorite example of mine is a bug in Word 2007 where, in certain circumstances, Word would write out the oMath element before the rFonts element, whereas the standard clearly states that the oMath element should be written out after the rFonts element. This was a minor bug that was simple to fix and is characteristic of many of the changes we made.
Because we were changing some of the syntax of the files we write, we also did work to ensure that customers using previous versions of Office could continue to work with files using this new syntax. First, we included fixes in Office 2007 Service Pack 2 to ensure continued compatibility. Second, we updated the Compatibility Packs for older versions of Office, too. In other words, if you have Office 2007 SP2 or the latest compatibility pack, interoperability with Office 2010 will be seamless.
We also went further than just ensuring syntax-compliance of the files we generate. We went through many of the accepted recommendations that various national bodies made during the ISO ratification process for Open XML, and identified a handful that we wanted to support in Office 2010. Here are a few highlights:
The first relates to our dependency on Vector Markup Language ( VML ). We heard clear feedback during the ratification process that depending on VML was a difficult requirement for other implementers. To lower this bar, we set out to reduce our dependency on VML, and have made great strides moving to DrawingML. PowerPoint 2010, for example, almost never makes use of VML as its primary method of representing drawing elements.
The second relates to the date syntax in spreadsheets. Again, during the ratification process, we heard lots of requests to add support for using the ISO 8601 Dates syntax for expressing dates in spreadsheets. Although currently in progress, Excel 2010 Beta includes support for this syntax. What is noteworthy about this investment is that we’re working closely with members of JTC 1 SC 34 ( the standards body responsible with Open XML maintenance ) to identify and resolve backward compatibility issues related to this new functionality. We’re particularly proud of this cooperation between Microsoft and the standards community.
The Relationship between Improving Interoperability and Innovation
As I talk to customers and partners about the work we’re doing to improve interoperability, I get asked lots of questions about how this quest to improve interoperability impacts our ability to deliver innovation in Office.
A few months ago at the Seattle, Washington DII event, one of my friends, Dr. Lee, a member of the JTC 1 SC 34 Korean National Body delegation, once asked me, what impact this focus on improving interoperability has on our ability to innovate in Office. It was a great question and the answer surprised many of the DII attendees.
My answer was simple: None. In fact, if anything, it makes it easier for us to innovate. The room fell silent.
From a technical perspective, there is nothing in the standard which prevents us from innovating. True, there are many rules and requirements we must follow. But there are also a number of technologies defined in the Open XML standard, MCE and extension lists, for example, which allow all implementers the ability to deliver compliant implementations, and, at the same time, compete in the marketplace on customer value. Microsoft Office, as we showed in that DII event, makes heavy use of these technologies to add all of the great innovations being delivered in the 2010 release, such as sparklines in Excel 2010 and new transitions in PowerPoint 2010.
I also pointed out that we fully documented both the Office 2010’s Open XML implementation as well as the technical details behind those innovations to ensure that all implementers had free access to that information. After all, this is about interoperability.
But the answer to Dr. Lee’s question was more than about technology. It was also about how working to improve interoperability has positively impacted the manner in which we build Office.
Interoperability has been elevated to the same level as other core design requirements of our products. Just as all of our features go through security and privacy reviews, performance and scalability testing, accessibility and programmability reviews, and international sufficient testing, we now approach interoperability the same way. Instead of documenting our file format implementations at the end of the release, we document the implementations during the release, while it’s being worked on. This provides countless benefits to the engineering team, allowing them to build features in a more efficient and more effective manner. It also makes on-boarding new employees, as well as load-balancing between employees, much more efficient given the wealth of documentation we have regarding our document formats. Ultimately, it is simply a great benefit to the entire design process. And fortunately it’s here to stay.
But it is more than just documenting your document format. It’s about continually looking for new ways to improve general interoperability between different vendors’ implementations. We recently held a DII event on the PST format used by Outlook. We did it not because we had to, but because it was the right thing to do. And based on the feedback so far, this was a great win for the industry.
I promised myself that I would limit this post to no more than two and a half pages. So for those of you who I have been unable to convince that our quest to improve interoperability hasn’t stifled our ability to innovate, I can only make one more suggestion to prove my case: go get the Beta. It’s well worth it.
As always, everyone working on Microsoft Office would love to get your feedback on ways in which we can improve the current state of interoperability. We hope that you’ll share our excitement for the Office 2010 release.
Group Program Manager, Microsoft Office
For More Information
|My System Specs|
|Our Sites ||Site Links ||About Us ||Find Us |
© Designer Media Ltd
All times are GMT -5. The time now is 01:30 AM.