Introducing the ODF Interoperability and Conformance TC

A short tale, all true, to relate. The names have been changed to protect the guilty.

Years ago, but not so very long ago, when XML still had that new car smell, two companies, let’s call them Red and Blue, decided to make a new XML-based standard. This new standard would be, they claimed, a huge step forward and would increase interoperability, especially in complex heterogeneous environments, with multiple operating systems, multiple vendors and applications, etc. Their activities received much fanfare in the press. Everyone was pleased that Red and Blue were cooperating together to make this new standard.

This wonderful new standard was eventually completed, and Red and Blue both went and implemented the standard in two implementations which I’ll call RedLib and BlueLib. But when they tried running their RedLib and BlueLib implementations against each other, to demonstrate interoperability, it didn’t work. It was a total failure. There was zero interoperability.

So what did Red and Blue do? They realized that interoperability is not guaranteed merely by the existence of a standard. You also need high quality implementations, implementations that accurately and completely implement the standard. For any non-trivial standard, implementation errors will dominate the list of causes of interoperability problems. So Red and Blue worked together, with other vendors, to create an interoperability lab for the new standard, and created test suites to test interoperability, and held interoperability demonstrations at conferences, and tested and iterated on this until the implementations provided a high level of interoperability.

Today billions of dollars are transacted every day using this XML-based standard.

With ODF we find ourselves in a similar, though more complex, situation. There are more vendors involved than just Red and Blue. We are starting with many commercial and open source implementations. In some cases, with some editors, interoperability is quite good. In other cases it is rather poor. But when a user loads a document, which they may have downloaded on the web, or received via email, they have no idea where that document came from, what application, what operating system. And when you create an ODF document, you may not know who will eventually read it. It isn’t enough to have good interoperability between some ODF implementations. We need good interoperability among all ODF implementations.

From a technical perspective, this is a goal we all know how to achieve. It has been done over and over again throughout the history of technology standards, especially network standards. You develop test suites, you test your implementations against these test suites, you have interoperability workshops (or plug-fests as they are sometimes called). You iterate until you have a high level of interoperability.

For the past 6 months I’ve been talking to my peers at a number of ODF vendor companies, to fellow standards professionals in OASIS, to ODF adopters, as well as to people who have gone through interoperability efforts like this before. I’ve given a few presentations on ODF interoperability conferences and led a workshop on the topic. I led a 90-day mailing list discussion on the ODF interoperability. Generally, I’ve been trying to find the best place and set of activities needed to bring the interested parties together and achieve the high level of interoperability we all want to see with ODF.

The culmination of these efforts is the creation of a new Technical Committee in OASIS, called the ODF Interoperability and Conformance TC, or OIC TC for short. The official 30-day OASIS Call for Participation went out last Friday. You can read the full charter there, but you can get a good idea by just reading the “Scope of Work”:

Initially and periodically thereafter, to review the current state of conformance and interoperability among a number of ODF implementations; To produce reports on overall trends in conformance and interoperability that note areas of accomplishment as well as areas needing improvement, and to recommend prioritized activities for advancing the state of conformance and interoperability among ODF implementations in general without identifying or commenting on particular implementations;

To collect the provisions of the ODF standard, and of standards normatively referenced by the ODF standard, and to produce a comprehensive conformity assessment methodology specification which enumerates all collected provisions, as well as specific actions recommended to test each provision, including definition of preconditions, expected results, scoring and reporting;

To select a corpus of ODF interoperability test documents, such documents to be created by the OIC TC, or received as member or public contributions; To publish the ODF interoperability test corpus and promote its use in interoperability workshops and similar events;

To define profiles of ODF which will increase interoperability among implementations in the same vertical domain, for example, ODF/A for archiving;

To define profiles of ODF which will increase interoperability among implementations in the same horizontal domain, for example ODF Mobile for pervasive devices, or ODF Web for browser-based editors.

To provide feedback, where necessary, to the OASIS Open Document Format for Office Applications (OpenDocument) TC on changes to ODF that might improve interoperability;

To coordinate, in conjunction with the ODF Adoption TC, Interop Workshops and OASIS InterOp Demonstrations related to ODF;

To liaise on conformance and interoperability topics with other TC’s and bodies whose work is leveraged in present or future ODF specifications, and with committees dealing with conformance and interoperability in general.

We have a broad set of co-proposers of this new TC, representing ODF vendors, ODF adopters, private sector and government:

• Robert Weir, IBM
• Bart Hanssens, Individual
• Dennis E. Hamilton, Individual
• Zaheda Bhorat, Google
• Charles-H. Schulz, Ars Aperta
• Michael Brauer, Sun Microsystems
• Donald Harbison, IBM
• Alan Clark, Novell
• Jerry Smith, US Department of Defense
• Aslam Raffee, South Africa Department of Science and Technology

The OIC TC will have its first meeting, via teleconference, on October 22nd. At that point members will elect their chairman.

I’d like to see broader representation in this TC’s important work. In particular, I’d like to see:

1. Additional vendors that support ODF, such as Corel and Microsoft (and yes, before you ask, I have already extended a direct and person invitation to Doug Mahugh at Microsoft)
2. A representative from KOffice
3. A representative from the OpenDocument Fellowship, which has already done some work on an ODF test suite. Wouldn’t it be good to combine our efforts?
4. Representatives from non-desktop ODF implementations, e.g., web-based and device-based.
5. Broader geographic participation.
6. Participation with specialized skills to help define and review test cases in areas such as: Accessibility, East Asian languages, Bidi text, etc.
7. People with an interest in archiving, to help to define an ODF/A profile.

So, if you fall into one of those categories, I hope you’ll consider joining the new TC. Heck, even if you are outside of those categories you are welcome to join. The only prerequisite is that you are an OASIS member. OASIS membership is $300 for individuals, and for companies has a sliding scale according to company size. More information on OASIS membership is here.

We have a lot of work to do, but now we finally have a place where we can get the work done. This is big. This is important, both for ODF vendors and ODF users. I hope you’ll join us as we all work to improve interoperability among ODF implementations!

[Update: On 12 November Doug Mahugh accepted my invite and announced that Microsoft would join the TC.]