Guess what the SC 34 committee, the ISO/IEC committee responsible for OOXML, is up to now? I call it a takeover attempt of ODF, according to my reading of the published notes of the most recent meeting held yesterday, October 1st, and starring a document titled "Request to JTC 1 for alignment of OASIS and JTC 1 Maintenance Procedures." Uh oh. That sounds polite, but it is what it is. An attempted coup. They have already sent a "Liaison Statement" to OASIS. Surrender or else, what? SC 34 asks JTC 1 "to establish with OASIS a synchronised mechanism for maintenance of ISO/IEC 26300 and to inform SC 34 of the outcome." I gather they think they can do a better job of maintaining ODF than OASIS. What will JTC 1 do, do you think? You doubt they will hop on to this wonderful plan?
I gather the hope is, if the takeover were to succeed, that SC 34 would get to maintain ODF as well as Microsoft's competing parody "standard," OOXML. How totally smooth and shark-like. Under the guise of
"synchronised maintenance", without which they claim SC 34 can't fulfill its responsibilities, they get control of everything. So utterly Microsoft. Microsoft yearns for interoperability, it seems. More like yearning for ODF's air supply to be ... well, you know. Microsoft never seems to change, does it? Yoo hoo! EU Commission! Are you watching? You can read all the public resolutions of the ISO/IEC JTC 1/SC 34 Plenary Meeting, 2008-10-01, held in Jeju, Republic of Korea. It will either make you laugh or throw up. I did both. Sequentially.
Actually, you can only read part of the resolutions passed by this stacked committee. As usual, there are deep secrets that the public can't access. That's just one part of what's wrong with those people and why ODF must never fall into their secretive clutches. If it does, I have little doubt that ODF will end up brain dead, on life support, turning blue for lack of oxygen, and then suddenly, sadly, we'll find it dead as a doornail.
Why do I say Microsoft, when this is SC 34? Look at this, will you? It has a list of participants in the July meeting in Japan of the SC 34 committee. The committee membership is so tilted by Microsoft employees and such, if it were a boat, it would capsize. In fact, I'd say it already has. Of the 19 attendees, 8 are outright Microsoft employees or
consultants, and 2 of them are Ecma TC45 members. So 10 out of
19 are directly controlled by Microsoft/Ecma. Any questions?
And here's yesterday's Resolution 6:
Resolution 6: Liaison Statement to OASIS
SC 34 approves the liaison statement contained in SC 34 N 1095 and instructs its Secretariat to forward it to OASIS together with the defect report on ISO/IEC 26300: 2006 contained in SC 34 N 1078.
Resolution 6: Request to JTC 1 for alignment of OASIS and JTC 1 Maintenance Procedures
SC 34 approves SC 34 N 1098 for submittal to the JTC 1 Plenary meeting to be held in Nara, Japan in November 2008.
The liaison statement forwarded to OASIS is not being made public. Neither is the SC 34 N 1098 document "for submittal to the JTC 1 Plenary meeting" being planned for next month.
Here's the meat of the sooper seekrit document 1098, however, so you can see the scheme in all its glory:
Request to JTC 1 for alignment of OASIS and JTC 1 Maintenance Procedures
They imagine that they are better equipped to handle ODF than OASIS, I gather.
Well, they are a day late and a dollar short, methinks. As it happens, there already is a technical committee set up to handle ODF issues, the just-announced OASIS ODF Interoperability and Conformance Technical Committee.
34 is anxious to fulfil its obligations for maintenance of standards
assigned to SC 34 by JTC 1. These standards now include both ISO/IEC
26300:2006 and the shortly-to-be-published ISO/IEC 29500:2008.
34 and Ecma International have spent considerable time over the past
two years discussing and agreeing maintenance arrangements for ISO/IEC
29500, and we believe that we now have agreed an arrangement that meets
the goals of timely maintenance of an ISO/IEC standard in accordance
with the procedures of both ISO/IEC and Ecma International.
SC 34 would like to have had a similar discussion with OASIS concerning the maintenance of ISO/IEC 26300.
strong support that has recently been shown for SC 34 to produce a
Technical Report on translation between ISO/IEC 26300 and ISO/IEC
29500, supported by 18 Members, demonstrates that SC 34 is the centre
for standardization of editable document formats within JTC 1. To
fulfil this role, SC 34 needs to be closely involved in the maintenance
and revision of the standards for which it has responsibility.
and JTC 1 do not have a synchronised mechanism for maintenance of
standards. The maintenance arrangement agreed between OASIS and JTC 1
fails to establish such a mechanism, so that SC 34 is unable to
maintain ISO/IEC 26300 in accordance with the JTC 1 Directives and in
fulfilment of SC 34’s responsibilities.
34 therefore requests JTC 1 to establish with OASIS a synchronised
mechanism for maintenance of ISO/IEC 26300 and to inform SC 34 of the
Here's a comical touch, how the SC 34 committee at the July meeting suggested handling defect reports regarding OOXML:
4.5 Defect Handling
- [Note: ISO/IEC JTC 1 SC 34 Ad Hoc Group 2 is developing a web application for collecting defect report comments for 29500.]
- WG 4 should adopt the web application of AHG 2, but it shall be for the use of NBs only for the submission of defect report comments. JTC 1 Directives require the submission of defect reports through recognised bodies.
- [Note: Form G5 may still be used for comment submission by NBs.]
- The above does not prevent other, informal mechanisms existing outside the process for comment collection from non-NB contributors. We encourage the establishment of such mechanisms, so that public comments are properly routed through NBs to WG 4.
- SC 34 may wish to encourage NBs to engage with the broader community and submit defect reports.
They may. But I doubt they will. Should be a blast if they do, but really, why would anyone bother to submit a defect report, considering how many were totally ignored at the BRM and thereafter, even to today? Unless they decide to engage with us unwashed masses, you'll note that the formal process is for "member bodies" only. Us hoi polloi can just wait for "informal mechanisms" to be set up someday, if they decide to do so. That should keep the finger-pointing at mistakes down to the loyal few.
I suggest they start there at the BRM, though, if they want to find defects to fix. X marks the spot. Include the issues from the NBs whose microphones were turned off when they tried to speak, will you? That seems a logical place to get going fixing the unfixable OOXML. Then tackle the appeals next, I'd think.
Considering that ODF is already in use around the world, and OOXML is still being pulled together into a workable shape, why would ODF leave OASIS and go to the home of a "standard" that isn't done yet, my logical brain asks? Riddle me that, Batman. Send OOXML to OASIS, by all means, if synchronization is desired.
I know. I'm just saying, if they were sincere, it would reach the purported goal faster and more reliably, if the folks that actually were able to produce a workable standard took over OOXML instead of the other way around. Here's the latest adoption news, by the way, Brazil's announcement that it is using ODF. Seen any announcements lately about OOXML? Ever? Perchance because OOXML is an unfinished mess? And ODF is already working just fine, despite all the effort this committee has put forth to make ODF look bad. Here. Take a look. This is what the SC 34 folks came up with for defects in ODF. That's it. I'm sure they'll keep looking, here's the level of defects put on their list:
What does "the current chapter" mean? No kidding. I couldn't make that up. It's Defect Report JPT2-5, "Request for clarification".
I have a suggestion. I suggest they could more profitably use their time fixing OOXML's rather significant defects. Alex Brown tells us, in his blog account of the recent meeting, that the UK had 600 changes mandated at the BRM that it will now need to check to make sure they were implemented correctly. It seems at least one from Japan was not:
The afternoon was devoted to OOXML matters. Evidently, the sudden appearance of the final text of ISO/IEC 29500:2008 has come as something of a surprise for many; and the appearance of the first defect report (from Japan) shortly thereafter was a shock. Suddenly it’s all real; the clock is ticking and the Project Editor is obliged to respond to Japan’s report in eight weeks. Murata Makoto (the convenor of WG 1) carefully explained the details of the maintenance regime and took us through an example of one of the Japanese defects, which centred on a BRM-mandated change (from Finland) that had not been properly implemented in the final OOXML text. No doubt other NBs, as a priority, will now scour OOXML to make sure “their” changes have been implemented, and submit defect reports accordingly where they have not. The UK, with its 600 or so accepted changes, has a lot of checking to do …
Obviously, these folks have their hands full. Let them get cracking on the task at hand, I say.
Who attended the SC 34 meeting in July?
Bergius, Kimmo (FI) [Tuesday only]
Brown, Alex (GB) [convenor]
Cave, Francis (GB)
Farquhar, Adam (Ecma)
Jaeschke, Rex (Ecma)
Lange, Pia Elleby (DK)
Leenaars, Michiel (NL)
Mahugh, Doug (Ecma)
Makoto, Murata (JP)
Nobik, Lajos (HU)
Opota, Wemba (CI)
Paoli, Jean (Ecma)
Roberts, Brett (NZ)
Sebestyen, Istvan (Ecma)
Setälä, Manu (FI)
Simonsen, Keld (NO)
Stocholm, Jesper Lund (DK)
Stride, Jean (GB)
Valet-Harper, Isabelle (Ecma)
Welsh, Dave (US)
They seem to have left off the affiliations here and there, so let's help them out. Here's my list:
Bergius, Kimmo (FI) [Microsoft employee]
Alex Brown (GB; convenor; founding director of Griffin Brown Digital Publishing "a UK-based company providing XML-based services and products" and member "British Standards Institute (BSI) Technical Committee IST/41, where he contributes to ISO/IEC JTC1/SC34"]
Cave, Francis (GB) [chair "BSI Technical Committee IST/41, which represents the UK in the work of ISO/IEC JTC 1/SC 34" and "has operated a successful freelance XML consultancy business since 1999" - Francis Cave Digital Publishing]
Farquhar, Adam (Ecma) [Ecma TC 45 member]
Jaeschke, Rex (Ecma) (Microsoft consultant, Project Editor for OOXML)
Lange, Pia Elleby (DK)
Leenaars, Michiel (NL)
Mahugh, Doug (Ecma) (Microsoft Employee)
Makoto, Murata (JP)
Nobik, Lajos (HU) (IBM)
Opota, Wemba (CI) (Microsoft Employee)
Paoli, Jean (Ecma) (Microsoft Employee)
Roberts, Brett (NZ) (Microsoft's, National Technology Officer for New
Sebestyen, Istvan (Ecma) (President of Ecma)
Setälä, Manu (FI)
Simonsen, Keld (NO)
Stocholm, Jesper Lund (DK)[His mainly favorable report on the BRM]
Stride, Jean (GB)
Valet-Harper, Isabelle (Ecma) (Microsoft Employee, Chair of Ecma TC45)
Welsh, Dave (US) (Microsoft Employee)
There. That's better. Information wants to be free.
And here's Resolution 22 from yesterday, so we can all give credit where credit is due:
Resolution 22: Appointment/Confirmation of Liaison officers
SC 34 confirms its Liaisons and officers as follows:
IEC/TC 100 Dr. Yushi KOMACHI
ISO/TC 46 Dr. Sam Gyun OH
JTC 1/SC 22 Mr. Rex JAESCHKE
JTC 1/SC 29 Dr. Yushi KOMACHI
JTC 1/IT Vocabulary MT Dr. Patrick DURUSAU
ECMA/TC 45 Dr. Makoto MURATA and Mr. Rex JAESCHKE
OASIS Dr. Patrick DURUSAU
XML Guild Mr. G. Ken HOLMAN
One can't help but notice this from Brown's blog:
Day 0 had been concluded with a tasty Korean meal (washed down with possibly a tad too much Korean vodka) and it was very interesting to hear some of the views from NB members on how they thought the office formats future will play out (and no, there were no Microsoft, IBM or Ecma people at the table). One view was that ODF had served its purpose (to get MS formats out into the open) and should now declare victory before fading away gracefully; another was that OOXML would surely become the default format of the OpenOffice.org suite, and that this would crystallize the real option users had: to use FOSS or commercially-licensed Office packages. I'm not sure I'd go with either of these but still, it was refreshing to get some new perspectives rather than the stale repetitions that have too often characterised the exchanges of the past months. It will be interesting to see what really happens ... personally I think ODF is more likely to emerge as a kind of 'default choice' than OOXML (not perhaps, that most users care).... Oh, we care. Speaking for myself, I'd like to hear from Sun and OpenOffice.org on these thoughts that Brown has run up the flagpole to see if anyone salutes, as they used to say in the enterprise. In short, they hope, if I've understood his words from his alternate universe, that ODF will gracefully accept being euthanized by them and slip away into nothingness, having forced Microsoft to become more open.
Mr. Durusau, Mr. Brown, and all you guys, listen up, please. That isn't the goal. Microsoft being "more open" isn't the appropriate end goal. If it's your goal, you have utterly failed. The goal is a standard that anyone can use equally, a truly open standard, available to both proprietary folks and FOSS. Microsoft being "more open" but not really fully interoperable and always a little bit ahead of everyone else in its ability to use a "standard" is by no means enough. We've lived in that kind of Microsoft world a long time now. We don't need "standards" that replicate it.