The Office team have been busy again, this time publishing the implementation notes for the 1st edition of ECMA-376 in Office SP2.
Doug Mahugh has a full description of where to find the notes and how to use them;
Today we’ve published another set of document-format implementation notes, this time for the ECMA-376 1st Edition implementation in Office 2007 SP2. As with the ODF 1.1 implementation notes we published in December, the goal of publishing these notes is to help other implementers improve interoperability with Office, by transparently documenting the details of our implementation.
To get to the ECMA-376 implementer notes, go to the DII home page and click on Reference and then select ECMA-376 1st Edition from the dropdown list. You’ll then see a treeview control in the panel on the left, which contains the entire structure of the ECMA-376 spec.
… and Eric White brings up an example of where these types of notes are useful to developers;
As a good example of an implementation note, standards sometimes don’t specify limits on the lengths of specific values. In some places, the ECMA-376 standard only makes recommendations about limits on value lengths. But as we all know, in real-world applications, to build robust applications that perform well, there sometimes must be limits on lengths of values. The standard doesn’t state that there should not be a limit; a conforming application can limit value lengths. When you want to write SpreadsheetML documents that Excel 2007 can open, it is useful to understand the limits.
For example, in the Shared String Table, section 3.4.12 documents the t (Text) element. The standard doesn’t indicate the maximum length. However, we learn from the implementation notes that Excel restricts the value of this element to 32767 characters. Knowing this limit in Excel allows developers to make sure that the spreadsheet documents that they create to be opened successfully by Excel.
Stephen Peront also has a good description of how to use the notes. Stephen is a new member of the Office Interop team and I suspect his blog will become a great resource for technical information in this area.
It is worth looking at why these types of notes are so important, implementation of standards in products is never an easy task, and these types of notes make it incrementally easier for developers to do so.
Here are a few examples that I used in a presentation here in Singapore last week;
Standards have gaps that each implementer must fill. In the ODF context, for example, the spreadsheet specification does not address the use of formulas. In OXML, ranges can be established in a variety of different ways. Each developer must, therefore, devise its own method of addressing these gaps. Transparency is important, however, because each implementer needs to understand what choices other implementers have made.
Some aspects of standards are vague. In many places, ODF is not sufficiently detailed for developers to choose the same implementation path. For example, ODF does not specify how data in a chart should be laid out. The OXML standard similarly does not specify a maximum length for a header caption in a pivot table.
Products and standards are continuously evolving. The OXML standards maintenance process will begin in late January. This is neither surprising nor an indication of OXML’s deficiencies; rather, it is the normal process by which standards evolve over time. At the same time, OASIS has already produced one update to ODF 1.0 standardized in ISO/IEC (ODF 1.1, adopted by OASIS last year) and is working on a second update at this time (ODF v1.2).
Clearly, as ODF 1.2 gets published and makes its way through the ISO PAS process these examples become less relevant, but I think that just goes to support the point that developers have to make their own decisions as they implement ever evolving standards.
In an earlier post Doug took a look at some of these interoperability challenges, pulling on real world examples that he stumbled across in his own testing;
I’ve started testing interoperability between various document-format implementations, and have found some interesting results. There are some very comprehensive tests of document format interoperability beginning to emerge (see the University of Illinois study mentioned below, for example), but the things I’ve been doing are pretty informal: create a document, type something into it, do a little formatting, and save it. Even though these documents are very simple, I’ve run into some interesting results that illustrate the challenges faced by all implementers.
As part of that post he highlighted a report that has recently been published by Rajiv Shah and Jay Kesan at the University of Illinois looking at this issue of interoperability of open standards, and highlights a summary of their findings;
“We consider several implications of these results including the lack of perfect compatibility between implementations, the lack of good implementations outside of Windows, and the surprisingly good overall performance of OOXML implementations. The interoperability issues are troubling and suggest the need for improved interoperability testing for document formats. The results also highlight the importance of interoperability for open standards in general. Without interoperability, governments will be locked-in to the dominant implementations for either standard and in the process lose many of the benefits that might accrue from adopting an open standard in the first instance.”
We’ll continue to publish notes on how we implement document formats, and we’ll continue the discussions that have started in the Document Interoperability Initiative workshops.
It is through this combination of collaboration, publication of implementation notes, and use of standards themselves that we will eventually achieve cross implementation interoperability.
Sphere: Related Content