Open XML, ODF, PDF, and XPS in Office
Clearly the Press Announcement today from Microsoft will bring about another wave of discourse on the future of document formats. The really short version of this announcement is that Office is going to support ODF, PDF, and XPS in the product directly and Microsoft engineers are going to join the OASIS working group on ODF, participate in the future of PDF in AIIM, stay active in the Ecma working group for XPS, and of course, remain active in JTC 1 SC34 where Open XML (and hopefully ODF) will be maintained over time. Also, when released, Office 14 will update the already substantial support for IS29500 in Office 2007.
While this is a big deal announcement for the Office product team (check out Doug Mahugh's blog), my take on it is predictably focused on the longer-term interoperability factors. Each aspect of the actions being taken by Microsoft fit into a very logical progression.
For years, I have vocally disagreed with the notion of a single document format as being the answer – the oft quoted Highlander line, “there can be only one.” My reason for this is very simple – document formats are representative of the innovation in the applications that use them. If you mandate a single document format – or even worse, a single version of a document format – you are effectively saying that you want to constrain application innovation to the limitations of a given format. I think this is bad news for consumers and producers of technology alike.
There is a continuum of thought related to interoperability reaching back many years based on the growth of Microsoft’s enterprise business, all of which has been affected by the regulatory activity in the U.S. and Europe. This is overlaying the real-world issues customers face as the world continues to progress toward network ubiquity and the desire to exchange an ever-increasing range of data electronically. In particular, governments are pressing hard to realize eGOV scenarios where they are seeking to effectively connect just about every type of information processing technology ever created. Thus, we end up in an ongoing conversation about interoperability.
There are some points to keep in mind when considering the news about the expanded set of document formats in Office.
- This is not about any one document format “winning” – it is about enabling customers to evaluate and use document formats that make the most sense for them. Just as the MS deal with JBOSS didn’t mean we were saying that J2 was better than .NET – it is that we want our customers to have the most positive experience possible when using our product.
- Nothing in this announcement removes existing commitments regarding document formats. Microsoft will continue to support the open source translator projects. Why? Because we started them in good faith with customers looking to use that mechanism to achieve interop, because other developers are picking up the platform agnostic projects and implementing them, because the collaborative development in the OSS projects has been educational for people on all sides of the interop issue. (Witness the work of DIN – the German national standards body – and their move to have those translation technologies become ongoing work in JTC 1 SC 34 WG6).
- The Data Portability aspects to the Interop Principles will continue to move forward. For example, the API that will allow ANY document format to register itself with Office and be set as the default will be made available as planned. Additionally, the work with DAISY and other specialized document formats will move forward as well.
- The documentation of client/server protocols for Office-related technologies (such as SharePoint and Exchange/Outlook communications) will remain available to the public.
- Microsoft will continue to listen to customers about specifications’ version numbers and look at the practical nature of software implementation as we make decisions about what to implement. Office is NOT implementing ODF 1.0 from ISO. That spec is not representative of the marketplace today, it is not what is implemented in OpenOffice, it is not what IBM is using for Symphony, and it is not referenced in the Massachusetts ETRM policy. We are looking carefully at the business, customers, marketplace and competitive issues for each of the specifications and the MS implementation work will depend on those considerations.
- Participating with quality engineering capacity in Open XML, ODF, PDF, and XPS working groups will pay dividends for our customers over time. I know that the skeptics are going to spin theories about MS participation in these groups – but the reality is that we want the specs to continue to improve over time and facilitate interop so that our customers are happy with the value they receive from our solutions. Clearly product competition is always a factor in this discussion, but that is the exact reason standards bodies exist – so all parties (even direct competitors) have a neutral forum in which to work on specifications.
The next 12 to 24 months are going to be extremely telling in the world of document formats. The myopia around the standardization process of Open XML will fade as software producers continue to invest their development budgets in the creation of solutions. The specification itself is only the start; it is the implementations, and the competition in the marketplace of broader solutions that will continue to matter more. In my opinion, the continued interest in innovation presented by those solutions will speak much louder than the formats themselves.