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.
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:
There are two other particularly important investments we’ve made based on national body feedback provided via the standards process.
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.
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
Just to be absolutely sure, files generated/saved using Office 2007 SP2 or the latest compatibility pack are fully ISO/IEC 29500 compliant like Office 2010's versions?
Currently in my experience with a fully up-to-date copy of Word 2007 and then a fresh copy of Word 2010 beta, I have noticed that the new Wordart from Word 2010 (like what was introduced in Office 2007) does not display correctly in Word 2007. Will this be fixed, or will this remain an interoperability problem?
@odf: No, actually the changes made to Office 2007 SP2 and the Compatibility Packs only allow those components to open Office 2010-generated ( that is, ISO/IEC 29500-compliant ) files. When the files are resaved, the components will generate ECMA-376 First Edition files as they always have. Naturally, Office 2010 continues to support reading ECMA-376 First Edition files.
@Matthew: I suspect that what you are seeing is the down-level representation of the WordArt object created in Word 2010 being rendered in Word 2007. For example, such WordArt text is likely rendered as bold text in Word 2007. This is because Word 2007 does not have the new rendering technology that was added in Word 2010 for the new WordArt feature. This is a great example of the trade-offs required in designing cross-version file format structures. In this case, the Word team needed to decide what was more important for the customer when opening a file in Word 2007 that contained Word 2010 WordArt: would the customer prefer to maintain visual fidelity, in which case a picture would have been the optimal alternative representation, or would the customer prefer to maintain editability, in which case bold text would have been the optimal alternative representation. In this case, based on extensive customer understanding, the Word team elected to optimize for editability. That said, we’d be very interested in your perspectives here.
What are plans in supporting new OpenXML (word 2010) in .NET (Open XML SDK 2.0)?
I have several programs written for our company where I'm using .docx generation - what are correct plan for upgrading OpenXML SDK to 2010? What about compatibility mode?
We will be adding Office 2010 Open XML support in the next CTP of the Open XML SDK 2.0. Check out the following post for more information:
In that next CTP release, to be released very soon, we give you the ability to choose how to pre-process your Open XML files according to Office version. For example, you will be able to open any Open XML file the way Office 2007 or Office 2010 understands
it. Stay tuned for more details on the following blog:
I'm not sure what "Open XML" is -- do you mean "Office Open XML" aka OOXML?
In any event, I don't have a need to use OOXML at all. I need ODF.
Will you be posting a webpage comparable to this one but discussing ODF instead of OOXML?
I want to learn more about what Microsoft is doing to support ODF. Thank you.
@odf: Yes, Open XML is synonymous with Office Open XML, OOXML and ISO/IEC 29500.
It’s great to hear that you’re interested in using Microsoft Office’s ODF implementation. Office 2010 supports ODF version 1.1. This is substantially the same as the way ODF works with Office 2007 SP2. There has been a lot of discussion about Office and ODF on Doug Mahugh’s blog ( http://blogs.msdn.com/dmahugh/ ) and there is documentation for developers available here http://www.documentinteropinitiative.org/. It might also be worthwhile to check out a presentation Doug gave at OOoCon 2009 ( http://conference.services.openoffice.org/index.php/ooocon/2009/paper/view/67 ). Microsoft’s participation there was a natural extension of our ongoing work with the ODF community in standards maintenance and plug fests.
Please let me know if you need any additional information.
I have been an Office user since Office 4.3. Well really if you listen to feedback at all, as an Office 2007, I feel totally ripped off that the current supported release which will be just 1 release behind once 2010 ships won't support the ISO stnadardized version of Open XML. This is not the way to treat your customers MS. I am NOT content with mere interoperability. I want ISO compliant standards support in Office 2007, not the non-standard version which will eventually be phased out. You just lost one customer MS if you don't update 2007 and the compatibility pack with the ISO version. Making users upgrade to 2010 to get them to save in ISO standard format, bad business decision MS.
I've been reading about the recent ruling against Microsoft regarding the use of XML in Word and I'm a little vague on the details. Will the ruling have any effect on the docx standard? We are in the planning phase of several projects to leverage many of the Open XML features.
@Jack - Gray Knowlton has a blog entry on that topic here: