It has been a few months now since the OASIS ODF TC has done substantive technical work on ODF 1.2. We had a 60-day public review last summer, a 15-day public review last December and we will start another (hopefully final) 15-day public review starting this week. Every time we make a change to the specification in response to public comments we are required to have another 15-day review of the changes. This is all necessary procedural work, to make sure all stakeholders have the opportunity to comment. But it is not very exciting.
However, as the ODF 1.2 specification goes through remainder of its review/approval process in OASIS, we’ve increasingly turned our attention to ODF-Next. Tentatively (and we should have a TC vote on this work plan in the next few weeks), we’re looking at a two-year schedule for ODF 1.3, with four intermediate drafts (Committee Specification Drafts or CSDs). The first CSD would appear in September, 2011. We have not yet defined what features will be in ODF 1.3. So this is a great time to join the ODF TC, to “get in on the ground floor” for defining the next release.
While we await approval of ODF 1.2 and start work on ODF 1.3, we continue to maintain ODF 1.0 and ODF 1.1, the previous versions of ODF. And by “maintain” I mean we receive and track defect reports and publish corrections to the specification So effectively, the OASIS ODF TC is working on four versions of ODF.
Since the progression from ODF 1.0 –> ODF 1.1 –> ODF 1.2 –> ODF 1.3 is designed to be compatible, the average user will not notice a difference. Your ODF 1.0 documents should load just fine in your ODF 1.2 or ODF 1.3 editor. We try very hard not to introduce “breaking changes” that would cause trouble with older documents. Of course, the application vendor has a responsibility here as well, to pay attention to version compatibility issues. But from the perspective of the standard I do not believe that we’ve done anything that would prevent an editor from being (at the same time) a conforming ODF 1.0, ODF 1.1 and ODF 1.2 application. In fact, I’d expect most ODF editors today to be able to read any version of ODF, though they might only save the most-current version, or maybe the 2-most current versions.
An additional complexity is that we have ODF standards in OASIS and ISO. I’ve heard that some are confused by this, especially how these different versions correspond. I hope I can make this clearer.
You can be quite sure that this new competition did not escape notice in Geneva. As they say, “If you can’t beat them, join them”. Or in this case, get them to join you. One of the ways in which ISO/IEC JTC1 (the ISO committee that controls tech standards) responded was to introduce the Publicly Available Specification (PAS) transposition process. The idea here was to allow recognized standards consortia (and there is a formal ISO process to gain such recognition) to submit already-approved market relevant standards to ISO/IEC JTC1 for accelerated processing and approval as an International Standard. Essentially, such PAS submissions skip over the ISO Working Group and Subcommittee stages of work, and advance directly to a final approval ballot. This is a win-win situation. ISO has more relevant standards in its catalog, and consortia can continue to produce their work at a more nimble pace.
So when we look at the versions of ODF, we have more than just ODF 1.0, 1.1, 1.2 and 1.3. For each of these have an OASIS and an ISO version. And for each numbered version we have published corrections, and these are reflected both in the OASIS and the ISO catalogs. It sounds messy at first, but the important thing to note is that OASIS and ISO/IEC JTC1 have agreed to keep their corresponding versions of ODF “technically equivalent”. This was agreed to in a Memorandum of Understanding. This means that you should be able to use the OASIS or the ISO version according to your needs and have confidence that they are compatible. If you require an ISO version, then you can use that. If you want the very latest version, then use the OASIS version, since the ISO version typically lags by a year or more.
I hope the above diagram clarifies which versions of ODF are technically equivalent. Note that this is not a time line. The actual order that the various versions were published in is more complicated, since corrections to older versions of ODF can (and do) come after publication of newer editions. But this diagram shows the correspondence of “technically equivalent” OASIS and ISO versions of ODF. The big rounded blocks are published standards, the indented smaller ovals are published corrections (“Errata” in OASIS and “Corrigenda” in ISO), and the indented rectangle on the ISO side is an amendment.
In particular, note:
- OASIS ODF 1.0 corresponds to ISO/IEC 26300:2006
- OASIS has published two Errata documents for ODF 1.0, and both have corresponding Corrigenda in ISO, the first one already approved, the second one currently under ballot.
- OASIS ODF 1.1 + Errata 01 corresponds to ISO/IEC 26300:2006 + Corr.1 + Corr.2 + Amd. 1. This is a more complicated case, since we’re rolling up several corrigenda as well as the changes from OASIS ODF 1.1. But the net result is that after Amd. 1 is approved (and the ISO ballot is now underway) we will have an ISO version of ODF 1.1.
- The plan is to submit OASIS ODF 1.2 to ISO/IEC JTC1 under PAS transposition rules. I expect that we will receive defect reports on ODF 1.2, and these would be addressed as Errata in OASIS and Corrigenda in ISO, to maintain technical equivalence.
- Ditto for ODF 1.3. Once approved by OASIS, we submit for PAS transposition and maintain to preserve technical equivalence.
So this isn’t really all that complicated. We have a series of compatible ODF versions over several years. The technical work is done in OASIS, in a technical committee. Once approved by the OASIS membership the OASIS version of ODF is submitted under PAS rules to JTC1. Once approved by ISO, the OASIS ODF committee and the ISO ODF committee (called ISO/IEC JTC1 SC34/WG6) meet regularly to ensure that the two versions remain aligned, with specific attention to ensuring that we’re both looking at the same set of defect reports and keeping corrections in sync.