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:
- Introduction
- Scope
- Document Structure
- Metadata
- Text Content
- Paragraph Elements Content
- Text Fields
- Text Indexes
- Tables
- Graphic Content
- Chart Content
- Database Front-end Document Content
- Form Content
- Common Content
- SMIL Animations
- Styles
- Formatting Elements
- Datatypes
- General Attributes
- Formatting Attributes
- Document Processing
- Conformance
- 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.
You can follow the incoming comments via the TC’s comment list, or unofficially via the ODFJIRA Twitter feed.
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.
Do you know if ODF1.2 allow the patented MP3 to be included as a file format in a document?
ODF has the concept of a sound file that can be played in certain contexts, such as in a presentation. But the current draft does not mandate or prohibit any specific audio format. The range of formats is implementation dependent. I know that MP3 is supported, for example, in OpenOffice.
My personal preference would to identify everyplace where we allow an embedding, for image, audio or video, and mandate the support of at least one open format. This would provide a basis for interoperability for users who are targeting interoperability, while allowing users who desire MP3 or other non-open formats to use them as well.
However, I note that a similar attempt at mandating embedded media formats failed for the video tag in HTML5. I attempted to get a mandate for open image formats added to OOXML, and failed at that. I assume some of the same commercial interests that prevented those moves would also prevent achievement of consensus of an open embedding mandate in ODF.
The whole HTML5 codex fiasco is largely the result of major companies with preexisting investments in audio and video codices preserving their investments: Microsoft, Apple, Nokia (because of decoding hardware) , and to a lesser extent Google (because of their use of H264 on YouTube). In the wild, Safari and Chrome (closed source) support h264, but Chrome (and Chromium), Opera and Firefox all support Ogg Vorbis and Ogg Theora. Considering the fact that h264 has patents that last until 2028, I’m not sure how much traction it will have in the marketplace unless Google continues to use it for YouTube.
However, it should be noted that there is some suggestion that Google might open source VP8 and use it with YouTube at some point in the future, which is supposedly better than Ogg Theora, so the situation is still in flux.
Chromium does NOT support h264 native.
If one follows the precept of be liberal in what you accept, but be strict in what you offer, ODF should mandate that for interoperability, inserted objects must be in open formats, that is, a document with non-open format objects does not confirm to the ODF specification. Conversion routines for importing documents from other formats then would have to transcode, but at least you’d end up with something guaranteed readable. Of course, if you play a long game, patents on other formats will eventually expire, so, so long as somebody remembers how to decode the proprietary formats, it may not be an issue for archived documents.