September 2008

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:

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)
A representative from KOffice
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?
Representatives from non-desktop ODF implementations, e.g., web-based and device-based.
Broader geographic participation.
Participation with specialized skills to help define and review test cases in areas such as: Accessibility, East Asian languages, Bidi text, etc.
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.]

Although the ODF 1.0 standard was approved several years ago (by OASIS in 2005 and by ISO/IEC in 2006), work on the standard does not cease. Of course, we have work on technical revisions of ODF, in the form of ODF 1.1 and the current work on ODF 1.2. New releases make the news and are talked about at conferences. etc. But also important, though not talked about as much, is the ongoing work on the text of ODF 1.0., in the form of translation and error correction. Even after ODF 1.1 and ODF 1.2 are created, ODF 1.0 continues to be maintained.

Why is translation important? Aside from increasing the number of developers who can read the standard in their native language, translation is a prerequisite in several countries in order to make ODF into a national standard. So translation increases the number of places where ODF support can be an official requirement. So far the ODF 1.0 standard has been translated into Russian, Chinese, Spanish and Portuguese. (There may be others — Let me know if I’ve missed any.)

(Interesting to note the size advantage of ODF compared to OOXML. I’ve heard from one reliable source that to translate OOXML would cost $500,000. This will certainly hamper its ability to be adopted in some parts of the world. ODF, by reusing existing standards, is only 1/10 the size.)

Also in progress is a translation of ODF 1.0 into Japanese. From what I understand, a JISC committee has completed an initial pass of the translation and then passed the translation off to a second committee. This second committee is reviewing the translation and raising any issues where the text is unclear. In some cases this may be caused by a faulty translation. But in other cases errors may be found which were present in the original English text.

That’s the second ongoing activity related to ODF 1.0 — error correction. Although we received most of our comments during the mandated 60-day public review prior to approval as an OASIS Standard, we do continue to get a trickle of comments months and years after publication. Each OASIS TC has their own mailing list for receiving comments. For the ODF TC, the mailing list archives are here. Anyone can subscribe to the comment list and post using the instructions here. The additional complexity in the sign-up procedure compared to your average mailing list is to ensure that all feedback submitted by the public to the list is in accordance with OASIS IPR rules. This helps ensure that ODF remains an open standard, unencumbered by patents.

Although we are only obligated to address comments received during the pre-approval public review period, around a year ago the ODF TC decided to formally record and process all comments received, regardless of when they arrived. So far, from May 2005 to the present, we’ve received around 250 comments. We note each comment in a spreadsheet, along with what ODF versions it pertains to (ODF 1.0, ODF 1.1 or ODF 1.2 draft), what section number the comment concerns, and whether the comment is reporting an editorial error, a technical error, or proposing a new feature. My estimate is that 50% of the comments are feature proposals, 40% are reporting editorial errors, and 10% reporting technical errors.

The preeminent source of comments on ODF 1.0 has been Murata Mokoto, of the Japanese SC34 mirror committee. Murata-san relays to us the defects found during the Japanese translation of ODF. The vast majority of these are editorial errors, mainly typographical or grammatical. But there are a handful of more significant issues found, and we are especially pleased to receive reports of these.

You may recall the old saying, “Every new class of users finds a new set of defects”. Translation of a standard is a laborious process, especially when combined with the additional review step that JISC is engaging in. This has subjected the text of ODF 1.0 to more scrutiny, at a more detailed level, than any typical technical review could provide. So I am appreciative of the detailed comments from JISC, and of the effort made in this translation by them.

My personal aim is to ensure that all of the reported editorial errors are fixed in the ODF 1.2 text, and that any technical flaws are addressed via errata. An errata document (That’s what we call it in OASIS. Others, e.g., ISO, call it “corrigenda”) allows us to make small changes to the ODF 1.0 text to address defects.

But this goal certainly debatable. Why not aim to fix every reported error in ODF 1.0 via published errata? Why knowingly leave even the smallest typographical error in the text? What relative priority should be placed on fixing typographical errors (and others) in ODF 1.0 versus work completing ODF 1.2?

This is entirely at the will of the ODF TC. The combined priorities of the vendors and other interests represented on the committee determine the direction we take. My perception of the expressed interests is that we should address the JISC comments via an errata document, but that the overall priority is on completing the work on ODF 1.2, and not attempting to fix every last instance of subject/verb disagreement or misuse of “A” for “An” in ODF 1.0.

And so our work on the ODF TC follows that priority. I’d estimate that we spend 80% of our time on ODF 1.2 topics and 20% on processing public comments on ODF 1.0/1.1, including those from JISC. We are nearing completion of an official Errata document for ODF 1.0, consisting of fixes to defects reported by JISC. Expect to see a call for public review soon. After that, the TC will continue to review and process public comments from the comment mailing list. If warranted, we are able to issue an updated errata document in the future, to address additional issues as they are reported.

Archives for September 2008

Introducing the ODF Interoperability and Conformance TC

ODF: Translations and Errata