It’s been interesting to be a part of the ODF TC and learn about how an OASIS working group handles the maintenance work for an evolving standard. I’ve also been involved in INCITS V1, Ecma TC45, and more recently SC34 WG4, and each group has its own style, based on the governing rules, the personalities of the members and committee chairs, the nature of the work to be done, and other factors.
ODF 1.2 will be the next major deliverable from the ODF TC, and co-chairs Rob Weir (IBM) and Michael Brauer (Sun) have been leading discussions of various open proposals on the email reflector and in the weekly TC phone calls. Much progress has been made, and there are also many open issues remaining to be resolved.
One topic that has been debated extensively is the question of how to handle conformance in ODF 1.2. There is a new requirement in section 2.18 of the OASIS TC Process (http://www.oasis-open.org/committees/process.php#specQuality) which states:
A specification that is approved by the TC at the Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof).
The ODF TC has been discussing how the conformance clause of ODF might be modified for the 1.2 release to meet this requirement. This topic has been discussed in numerous weekly phone calls, and has become the most-discussed topic on the email reflector since I joined the ODF TC last year. There are currently over 200 emails on this topic in January and February of this year from 14 different TC members, including editor Patrick Durusau, well-known standards participants from South Africa (Bob Jolliffe), Brazil (Jomar Silva), Czech Republic (Jirka Kosek) and the US (Dennis Hamilton), ODF implementers (IBM, Sun, Microsoft, Novell, KOffice, Nokia, Adobe, Gnumeric), and others. Although the debate has been vigorous at times, it has all been conducted in a cooperative and respectful spirit of collaboration, and I’m sure I’m not the only person who has learned quite a bit from the discussion.
I’ll describe my perspective on the conformance debate in another post soon, but for today I just wanted to comment on the process we’re following, and how this debate is (hopefully) leading to consensus on this topic.
In December, Sun’s Michael Brauer (originator of the conformance proposal) revised his proposal to include one-level and two-level conformance alternatives. We then started discussing this in some detail in early January, as mentioned above.
The agenda for the January 19 TC call listed the conformance proposal as a discussion topic, and the minutes of that call state that “no consensus” was reached on the proposal. Then the agenda of the February 9 call included this item:
7. Discussion of Conformance Proposal, Version 8. http://lists.oasis-open.org/archives/office/200902/msg00058.html [Note: The Chair declares his intent to have a vote to approve this proposal during the meeting, if he perceives a consensus. Otherwise his intent is to request a 7-day electronic ballot on whether the proposal shall be approved]
The next call was this week’s call on Monday 2/16, and the agenda for that call didn’t mention the conformance proposal, although it does include an item for “Approval OpenDocument v1.2 draft 9 as Committee Draft.”
I didn’t attend this week’s call, as I’ve not attended several calls lately. Stephen Peront has been taking over responsibility for ODF and OIC TC engagement on our team, and he reported to me that the call included a vote on a new draft of ODF 1.2, which included the conformance proposal. Stephen felt he had to vote no on the committee draft, because it includes a conformance clause that we (and other TC members) have said isn’t yet ready.
Now I see that Rob Weir (IBM), co-chair of the ODF TC, has blogged about Monday’s approval of the latest committee draft, and he includes this paragraph in his post:
We also need to socialize and grow consensus around ODF 1.2, both from implementers, but also adopters and consumers of ODF. There is still work to be done here. For example, the TC vote on the Committee Draft 01 was not unanimous. We did not have the support of Microsoft or Novell. There are still disagreements over how we define conformance in the standard. We obviously need to continue discussing this topic. Since the final TC vote to request an OASIS Standard ballot requires 2/3 approval of TC members with no more than 25% disapproving, we'll need a high level of consensus in the TC to move forward, including, hopefully, the support of Microsoft and Novell.
It’s not clear to me why Rob singles out Microsoft and Novell by name here. As you can see from the minutes of the meeting, Novell abstained, as did Dennis Hamilton. Dennis is not affiliated with a large vendor, but he is one of the most prolific contributors to ODF 1.2 in recent months.
As a person watching the ODF 1.2 process from a slight distance (reading the emails but not attending recent calls), it’s odd to see that the chair’s perception of a need to vote on the proposed conformance clause seems to have disappeared, and instead the clause was inserted into a committee draft at the last minute. It feels a bit like “pork” (to use an American slang political term), but I’d love to hear another explanation if there is one. The chair’s role is to determine consensus, so if the chair has determined that there is clear consensus on the conformance clause, that would be interesting to know. As it stands, my colleagues Stephen and Eric Patterson felt they couldn’t approve a draft that had a non-resolved issue inserted without clear consensus, and I agree with their decision. As stated in the minutes, “Some TC members that voted with "no" indicated that their "no" vote is due to conformance clauses which are included in the draft.”
Speaking of watching from a distance, it’s interesting to note how the large vendors have been conducting themselves in the gear-up toward final approval of ODF 1.2. OASIS rules allow each member to have a vote (as opposed to the rules in organizations like INCITS V1, where each company has one vote), so it’s possible for a large vendor to have multiple votes. For Microsoft, I’ve stopped attending the calls (and thereby lost my voting rights) while Stephen Peront has started attending (and gained voting rights), so we still have two voting members. I believe Sun has three voting members currently, and IBM is apparently up to four voting members, having added Don Harbison last week and Ma Yue this week.
I’ll revisit the conformance proposal soon, to explain our position in more detail. Meanwhile, if anyone can help me understand the process better, please let me know in the comments below. I remain hopeful that we’ll get an ODF 1.2 completed that will reflect the consensus of the TC.
The ISO/IEC Directives Part 2 Annex H (which defines these usages), provides equivalent forms which help to explain these meanings. Broadly:
shall = has to
should = ought to ("it is recommended that")
may = is allowed to
can = is able to
in the references.odf document posted by Rob Weir I read
"[OLE] Kraig Brockschmidt, Inside OLE, Microsoft Press, 1995, ISBN: 1-55615-843-2
This is a good book, but out of print. There must be some official Microsoft specification for OLE 2 posted on the web someplace. We should reference that."
Could you clarify the situation concerning available uptodate (online) documentation for OLE2 technology that could be easily referenced?
Andre, here's a link to the latest OLE documentation online: http://msdn.microsoft.com/en-us/library/cc313062.aspx
Thanks doug. That explains it better.
I would prefer standards using terminology like
"it is recommended that"
which is easier to interprete in a world where not everybody is a native english speaker but many are likely to encounter standard text in English whem inplementing it
I don't agree with you here. It is important when reading/writing a standard that the vocabulary is consistant.
Remember that a standard is essentially a set of rules to follow when implementing it. I actually like that the wording is consistant across standards.
Everyone making guides and "how-tos" are more than welcome to use more "everyday language", but I think the wording in standards should remain the same.
I think it is poor wording because I now get the impression that shall will often beinterpreted as "not required" and as such has no more formal conformance requirements than "may" or "can"
I do not consider that to be very consistant already.
I will also direct you to a dictionary
Where you can see that "shall" is multi interpretable english that can refer to mandatory or must requirements
I think it is very bad to use that kind of interpretable language in standards especially in a world where more an more english written standards are used by non-english speakers.