A major milestone was reached for the OASIS ODF TC today. The latest Committee Draft of ODF 1.2 Part 1 was sent out for a 60-day public review.
“What does this mean, and why should I care?” you might be asking. That’s a fair question.
First, a quick review of the OASIS standards approval process. The stages look like this:
- TC creates one or more Working Drafts
- A Working Draft may then additionally be approved as a Committee Draft
- A Committee Draft may then be additionally approved as a Public Review Draft
- After addressing received public comments, a Committee Draft may be approved as a Committee Specification
- Finally, a Committee Specification may be voted on by OASIS as an OASIS Standard
There is the possibility of iteration at most of these stages. So we’re not done with ODF 1.2. There is still work to be done, but we are certainly in the endgame now.
Also, it is important to remember that ODF 1.2 has been factored into three “parts”:
- Part 1 specifies the core schema
- Part 2 is OpenFormula (spreadsheet formulas)
- Part 3 defines the packaging model of ODF, and went out for public review back in November
Part 1 is by far the largest of the 3 parts, at 838 pages. Here is a high-level view of what is covered:
- Document Structure
- Text Content
- Paragraph Elements Content
- Text Fields
- Text Indexes
- Graphic Content
- Chart Content
- Database Front-end Document Content
- Form Content
- Common Content
- SMIL Animations
- Formatting Elements
- General Attributes
- Formatting Attributes
- Document Processing
- Appendix A. OpenDocument Relax NG Schema
- Appendix B. OpenDocument Metadata Manifest Ontology
- Appendix C. MIME Types and File Name Extensions (Non Normative)
- Appendix E. Recommend Usage of SMIL
- Appendix G. Acknowledgments (Non Normative)
If any of this interests you I’d encourage you to take a look at the draft and submit comments per the process defined in the public review announcement. I expect few will review the entire specification, but even if you can review only a chapter of particular interest to you, or even do a random page review, that will help. We’re looking for any reasonable feedback, from typographical errors, to ambiguities to new feature proposals. It is all good.
Now, I know that a vigorous public review, with many reviewers and many comments, is seen in some quarters as inconvenient and troublesome. It is thought better (in those circles) for standards to sail by, unread, unchallenged and unimplemented. I do not subscribe to that view. I ask you to not be gentle on the ODF 1.2 public review draft. Send us a lot of comments, so we know where we need to improve. Send us a lot of defect reports, so we know what to fix. Send us a lot of feature proposals, so we know what to do next. Short of joining the ODF TC directly, this is the best opportunity to give us feedback.