I used a variation of this chart at the recent ODF Plugfest in the Netherlands. But the aspect ratio of a presentation slide doesn’t suit this type of chart well, so here is a fuller version of what I showed there.
Those who are not familiar with standards development are sometimes amazed at how long it takes to develop a good standard. Perhaps the single-vendor, 6,000 page, 12-month escapade of OOXML in Ecma has skewed expectations. Fortunately, OOXML is the exception, not the rule. Achieving a multi-vendor consensus around a substantial technical standard will always be time-consuming, but it is time that is well spent.
OASIS standards go through several stages of development:
- Working Draft (WD)
- Committee Draft (CD)
- Public Review Draft
- Committee Specification
- OASIS Standard
Progressing from one step to another is by ballot. The first 4 stages are advanced by vote of the Technical Committee (TC), while the last stage (OASIS Standard) is by a ballot of all OASIS members. As a draft advances through stages 1-4, an increasing degree of consensus is required. So, a CD requires only simple majority, whereas a Committee Specification requires 2/3 approval, with no more than 1/4 disapproval. Some of these stages allow iteration. So we can, and typically do, have several WD’s and several CD’s.
If you want more detail on the nitty-gritty details, here is a flow chart of the OASIS standards approval process.
I occasionally get a question along the lines of: “What has the ODF TC been doing for the past couple of years?” The following timeline should give you an idea. I’ve indicated the time spent developing ODF 1.0 and ODF 1.1, along with some other milestone activities, such as the PAS transposition of ISO/IEC 26300, the publication of ODF 1.0 Approved Errata 01 and the creation of the various ODF subcommittees. I’ve also indicated the dates of each of the ODF 1.2 WD’s and CD’s.
As you can see, we’ve been quite busy. After iterating on WD’s during 2007 and 2008, we’ve now moved on to CD’s. This is not a drawn out process, but simply the ODF TC working with full transparency, making all of the intermediate drafts available for public inspection.
All of the planned feature work for ODF 1.2 is now completed. The remaining work is to address the various editorial and technical comments that have been submitted to our comment list, as well comments from TC members and JTC1/SC34. The goal is to have no known defects in ODF 1.2 before we send it out for a Public Review. Of course, previously-unknown defects will likely be identified during the Public Review, and we have a process for handling these. I’ll comment more on that process, and Public Reviews in general, when we get closer to that stage.
That is not a correct timeline.
Why are all working drafts and openformula work small same size blocks ?
It look like like the ODF 1, 1.1 and PAS submission follow a timeline (in which thery were produced) and the other elements in your table are just deliverables not showing any timeline for them to be produced.
ODF 1.0 and 1.1 had a similar process for producing Working Drafts and Committee Drafts. So you should think of the ODF 1.0 and ODF 1.1 bars in the timeline as collapsing all these subtasks for those releases.
For the ODF 1.2 tasks, the blocks are the publication dates of each draft, they accurately show when the draft was released. But they are just points in time. That is why they are the same size. if it makes it clearer, you should think of each ODF 1.2 draft block as extending back to the previous draft.