Now that we're getting down to the final days of the DIS29500 standards process, it's interesting to see the tactics being used by those who have commercial interests that place them in opposition to this standard. Their tactics have changed quite a bit since the heady days of the DIS ballot period, and the most common tactic I've seen or heard of in recent weeks can be characterized as "changing the subject." It seems that there are people involved in the DIS29500 standards process (many of whom got involved quite late in the process) who want to convince various standards bodies to focus their time and efforts on a long list of proposed distractions, instead of the work at hand.
Whereas the work of evaluating a standard is technical, these proposed distractions tend to be emotional topics that are easy to convey quickly but don't shed any light on the core issues. And as the clock winds down on the DIS29500 process, some of the people who have vested interests in the outcome are really turning up the heat on the emotional topics.
A couple of supporting tactics are also used to add a multiplier effect to these efforts to derail the process. One is the tactic of dragging non-combatants into the debate without their permission. Another tactic is the longstanding Groklaw tradition of deleting comments that disagree with their statements, to reduce the risk of their claims being debunked publicly.
My colleagues Oliver Bell and Eric White have posted recently about the tactics of the anti-Open XML lobbyists, and I'd like to add a few to that list from my own experiences. Here are some examples of the sorts of things that various people are trying to convince standards bodies to think about these days, instead of the actual DIS29500 spec:
Process issues. A recurring piece of advice from some sectors is that standards bodies should change their vote to Disapprove as a statement on the Fast-Track process. Don't like the rules? Great, you can switch your vote to Disapprove without bothering to read any of the spec!
To state the obvious, each country's vote is on the DIS29500 specification and nothing more. It's not a vote on whether a BRM should allow visitors, or how the voting should be conducted, or anything else: it's a vote on whether DIS29500 should become an ISO/IEC standard. And if a country changes its vote, it should do so based on changes that have been made to the DIS29500 specification, and nothing else.
The final specification. Speaking of the final spec, another thing some people want to talk about these days is the question of whether there's a final spec available with every change already made. The anti-Open XML crowd has been trying to sell the concept that if there isn't a final spec available with every approved change already made, then countries "can't decide how to vote" and should therefore (decide to) vote Disapprove.
This one was explicitly addressed in the BRM, and it's pretty simple: the national bodies make their reconsideration decisions based on the documents that came out of the BRM.
As an ISO/IEC official explained to everyone in the BRM, there are two reasons for this approach. The first reason is that ITTF is responsible for verifying the accuracy of every change, and they don't have the resources to do this quickly. The second reason is that the process needs to be fair to all countries, and it would be unfair to have different documents available at different times during the 30-day reconsideration period. That might penalize those whose schedules required making a decision earlier in March, for example.
All national bodies have access to all of the documents describing all of the changes to be made, and that's what should form the the basis of voting decisions. If your national body has heard otherwise and needs verification of the ISO/IEC policy on this matter, they can contact ITTF directly to confirm the details. Communications directly from a national body to ISO/IEC get high priority, so that's the way to go.
Raising new technical objections. Many national bodies are being asked to consider brand-new technical objections to the DIS29500 standard, even though the 5-month period for submitting such comments concluded long ago in September. Then, when somebody points out that there is no process for resolving such comments until the future maintenance period, the lobbyists say "see, the process is broken!"
It's an easy tactic to try, because it's always possible to find a few more things that need correction in any large standard. Japan, for example, recently found a list of issues with the ISO ODF spec that has been out for a couple of years, and Brian Jones has a blog post today in which he takes a look at some of the ways common criticisms of Open XML apply equally to ODF.
The rules are pretty simple on this one: comments were submitted with the ballots (last September in this case), and any further technical concerns are addressed in maintenance. This is the way the process has always worked.
Talking about other standards, or non-standards. This one really takes the cake for pure chutzpah. Some vendors (Microsoft competitors, frankly) are going to national bodies and telling them to consider alleged problems with other standards instead of DIS29500. Sounds crazy, but it's really happening.
For example, one big US-based vendor is shopping around a list of complaints about an RFC that Microsoft has submitted to IETF as a courtesy, to make the Pack URI portion of OPC more broadly available. This isn't even a normative document, and isn't referenced in the DIS29500 specification at all, but for some reason this vendor thinks national bodies should be spending their time this week studying a Microsoft competitor's reaction to it.
Extending the reconsideration period. This is another creative tactic: telling national bodies that they should ask to have the reconsideration period extended from 30 days to some longer period of time. The advice is never a straightforward "ask ISO/IEC if there's a way to do this," but rather a more roundabout "vote Disapprove and say you might change your mind if you had more time."
This topic was discussed a year ago, and ISO/IEC have been consistently clear that the decision on DIS29500 would be reached at the end of this month. This was explicitly said in the DIS29500 session held at the JTC 1 Plenary last fall in Australia, and there is no defined procedure for ISO/IEC to extend the reconsideration period. So this advice is essentially "ask for something we know they can't do, then vote Disapprove to indicate your unhappiness about it."
Casting this as a "new vote." This is a subtle one: the claim that countries must vote again. That's not accurate: this isn't a "vote," but rather an opportunity for reconsideration of a country's position from last September based on changes that have been made to the spec, or information that the national body has received which they didn't have last September. So, for example, if a country voted Disapprove last September but many of their comments were addressed in a satisfactory way, they could now change that vote to Approve.
One thing that can cause confusion on this point is the difference between ISO/IEC and JTC 1 Fast-Track processes. DIS29500 is going through a JTC 1 Fast-Track process, and in that process there is not a final vote, only a reconsideration period during the 30 days after the BRM. But in the ISO/IEC Fast-Track process, there is another final vote, as described in the ISO/IEC Directives Part 1, Annex F.
It's quite rare for a country to shift their vote in a negative direction at the end of a JTC 1 Fast-Track process, by the way. (I think only one country has ever done that -- anyone know for sure?) The reason is obvious: if you have a BRM and make a bunch of changes or improvements that countries asked for, then the spec is probably better than before, or at the very least no worse than before.
Re-raising contradiction-period comments. This is one that's come up very often: vendors telling national bodies that they should consider the comments raised during the contradiction period (January of last year), such as the claim that DIS29500 isn't appropriate for a Fast-Track process.
These comments were raised during the contradiction period, Ecma responded as required, and ISO/IEC agreed with Ecma's responses and decided to start the 5-month DIS ballot period in early April. That's all ancient history now, but some of those working to defeat DIS29500 have gotten involved since then, and apparently don't know that.
What should a standards body do?
Some of those topics are interesting, and some are even relevant to standards work in general. But none of them can inform a voting decision on DIS29500: they're other topics that one might ponder in other contexts.
So how can standards bodies best inform their decisions on DIS29500? I think most people would agree that the best approach doesn't start with studying whatever random topic opponents of DIS29500 claim is important.
A good place to start would be to study the spec itself, and the other documents that will determine the final specification. If you're on a standards body involved in the process, you have access to all of these documents and should study them carefully:
And that's it: everything you need to study to reach a well-informed conclusion about DIS29500. You don't need to study documents prepared by big US-based vendors, web pages on lobbying sites, blog posts, IETF RFCs, or anything else. Just read and study the documents above, and you'll be among the best-informed participants in this debate.
Armed with that informed perspective, you'll be in a good position to protect your country's interests and take a long-term view of issues like interoperability, global competitiveness, job creation in the tech sector, retention and archiving considerations, and protection of existing investments. Your vote on DIS29500 will determine who will control the ongoing evolution of the standard, and whether your country has a say in that evolution.
Study the issues closely, avoid the distractions, and reach your own conclusions. This should be a rational process, not an emotional one.
Right or wrong, I'm not sure how you guys continue to put up with this crap. Keep up the good work.
It seems a bit disingenuous to claim the opposition is trying to change the subject, but then to praise Brian Jones for talking about ODF instead of OOXML. It is also a bit optimistic to think that you get to set the standard by which people decide to vote Yes or No (or Abstain). The reasons some NB might have chosen to approve before and not disapprove are that a) they believed the claim that the BRM process would significantly improve the spec, and b) they were unaware of technical issues that should lead them to disapprove. Very convenient to then try to shut down those who are focusing on the issue, such as Rob Weir, because all the comments should have been made in the earlier 5 month period. There is absolutely nothing in the process that says that. Every NB has a responsibility to look at the spec, preferably the one with changes made after the BRM, but that is not available, and decide whether it should be approved. If new issues are found which call into question their earlier approval, they should change it to disapproval. If they do not find new issues and are convinced that the BRM has improved matters enough, they should change their disapproval to approval. It is not a revote, but it certainly is an opportunity for BNs to decide if it would be best for their country and the world to approve the spec as it is, not as it could or should be.
Incidentally, I have read about 1000 pages of the original spec, and a wearying process it was indeed. I still think that it is a tremendous shame that Microsoft and Ecma did not spend more time on this before getting into this fast track process, and before hard wiring so many assumptions into Office 2007, because it would have made the spec better and all of our lives easier. There are so many changes that would have been easy to make back then that are difficult now. And of course, there are some small issues of the sort in ODF, but the process was far more open to change early in the process, which is why the end result is generally more usable for us third party developers.
"So how can standards bodies best inform their decisions on DIS29500? I think most people would agree that the best approach doesn't start with studying whatever random topic opponents of DIS29500 claim is important."
Is it true that you have been informed to stop responding on issues, because of the damage you have done with the Microsoft relations with the Malaysian government?
Anyway, Doug. I was in a meeting today with someone from a local standard body that had no clue that I was involved with the standard process. He bitterly complained about the way Microsoft handled the OpenXML process and the image problems their standard body faces. They are also afraid that regulators would step in and tighten control. I was very surprised.
I think for a standard body it is a matter of "raison d'etat" to burry the ISO OOXML fast track. I would recommend to listen to impartial persons, observers that are no stakeholders in this.
If the standards body fail to disapprove OOXML which is likely to happen it will cause severe problems for the international standards system. Microsoft will take the blame for the soil they put into ashes.
"You'll see a lot of duplication, including word-for-word duplication of specific comments across many countries -- that's from the "denial of service attack" strategy the anti-Open XML crowd was using during the ballot period."
Look at the comments and you see that to everyones great surprise that is not the case. In fact there are many errors that were not spotted by other standard bodies which gives you an indication of the limits regarding the review quality when you dump 6000 pages on a standard body.
"The comments from your country show the main concerns of your country, so you'll want to focus on those first, but you can also review other countries' comments as well."
I strongly disagree here. In fact it shows what other standards bodies spotted and your standards body was unable to find them. A bug is a bug, why should a standard body concentrate on its own bug reports? You need to consider the picture as a whole.
"And that's it: everything you need to study to reach a well-informed conclusion about DIS29500. You don't need to study documents prepared by big US-based vendors, web pages on lobbying sites, blog posts, IETF RFCs, or anything else. Just read and study the documents above, and you'll be among the best-informed participants in this debate."
Close your eyes! Wonderful suggestion.
"That's not accurate: this isn't a "vote," but rather an opportunity for reconsideration of a country's position from last September based on changes that have been made to the spec, or information that the national body has received which they didn't have last September. So, for example, if a country voted Disapprove last September but many of their comments were addressed in a satisfactory way, they could now change that vote to Approve."
Or change from "approve" to "disapprove" because in the meantime they found out that things are much worse than they appeared in September given the limited time to review. For instance because members didn't know that so many issues would be found. It is a second vote and no ratification process.
"This one really takes the cake for pure chutzpah. Some vendors (Microsoft competitors, frankly) are going to national bodies and telling them to consider alleged problems with other standards instead of DIS29500."
Who is making the comparison with ODF that you challenged with your crappy second standard? Who is talking about alleged ODF issues? The Microsoft communication policy was partly like "everone's got cancer". OOXML has enough issues. They are spotted, they are real and make OOXML as amended by the BRM "not ready" for becoming an international ISO standard. OOXML achieves this by its own virtues. The political debate, wheter there should be a second standard, if your company played fair etc. does even improve the case OOXML makes for its disapproval.
"To state the obvious, each country's vote is on the DIS29500 specification and nothing more". Wrong, and you're lucky that it's wrong. DIS29500 is a pretty awful spec, and if NBs were considering that alone then I think the vote would be much more heavily negative than it is.
In any case you contradict yourself in your incredibly leading penultimate paragraph: "protect your country's interests and take a long-term view of issues like interoperability, global competitiveness, job creation in the tech sector, retention and archiving considerations, and protection of existing investments"? "Determine who will control the ongoing evolution of the standard, and whether your country has a say in that evolution"? These are not technical considerations!
For the record, the BRM FAQ states that NBs may reconsider and if desired change their votes for any reason at all, and I hope that NBs consider all factors that they consider relevant.
And as for not allowing emotional factors into the discussion, if that was Microsoft's real intent, then why the slur e-mail from Microsoft New Zealand? (see http://nzoss.org.nz/news/2008/old-dog-reprise and linked articles). The hypocrisy is incredible. If I read another Microsoft blog stating that they are playing fair but the "other side" is bending the rules, I'm gonna barf.
So an NB can't vote No for procedural reasons, because it can only vote on the specification.
But it can't vote No because of problems in the standard either, because those can be fixed in maintenance.
So, Doug, why does JTC1 have a vote at all? Is this just a ceremonial vote?
Ben, I thought I was pretty clear about why I linked to Brian above: as an example of my point that "it's always possible to find a few more things that need correction in any large standard." I have never brought up any flaw in ODF in any standards body discussion, so I think my actions speak clearly on how I see the appropriateness of dragging other standards into those discussions, and I think Brian's post supports the point I was making.
As for problems in the spec, I'll let my public statements on that speak for themselves too. I've never claimed the spec is flawless, but I agree with those who feel that good progress has been made and good progress is going to continue in maintenance.
Andre, why do you say I've stopped responding on issues? What issues? To answer your question, no, I've not been instructed to do anything. We're more autonomous than you might think, and nobody at Microsoft has told me what to say or not say about any of these topics.
As for concentrating on a country's own comments, I can only speak from my own experience. In the US, the technical committee was asked to look first at the responses to our own comments, because those comments had (presumably) been based on our country's interests. I agree that it's worthwhile to look at other countries' comments too, and that's why I said what you quote above: "The comments from your country show the main concerns of your country, so you'll want to focus on those first, but you can also review other countries' comments as well."
In general, the emotional attacking tone of your comment, combined with its lack of supporting facts, is a great example of the proposed distractions I'm talking about. It's up to the national bodies to decide whether to listen to your advice or mine about what they should be studying to make a good decision.
Hi Rob (Weir),
I'd say an NB can and should vote no because of problems in the spec, if they think they're problems that make it inappropriate for the proposed standard to be an ISO/IEC standard. You and I disagree on the magnitude and relevance of certain problems, but I don't think we disagree on that point about whether problems should inform the vote.
So to get hold of the final text, I will need to
1) study Ecma 376. Which is 6000 pages
2) Read up on all the 3000 comments.. ok maybe 1027 comments
3) Read up the 2300 page proposed dispositions
4) ... while skipping the 1.6% which was not approved
5) Read the 43 resolutions from the BRM, which may affect the entire text, and add a few thousand text more (or remove, we arent sure)
Hmm. Sure! I could do that! Ive got 2 days before the final vote.
OK, so I'm going to be a bit naughty here. Sorry in advance, Doug, for the noise.
@Rob Weir: I'm generally supportive of the work you do, and our views on OOXML are in the same ballpark, but there are a couple of little issues I have:
It has been reported (see Jesper Lund Stocholm et al) that you remove contrary posts from your blog. You're free to do that, it's your blog and commenters are there at your discretion only, but don't you think it's a bit inconsistent to pop up on *their* blogs with contrary comments?
It's also been reported that you drop in with comments and then go AWOL when you're asked awkward questions. Again, nothing wrong there (some of my questions have been evaded or ignored by Microsoft people) but I'd really appreciate a response here.
It's just blog etiquette I guess, but I do admire the Microsoft bloggers' policy of allowing all comments even when they are contrary or critical. I've learned a lot from being able to ask questions around here and from an entertainment point of view, the Microsoft blogs are a colourful bunch of opinions whereas yours is a little bit... grey.
As part of the Malaysia delegation you had access to the revised version of the spec which had all 1,000 proposed resolutions applied (minus the multi-part one). So all you need to do is look to that draft, then study for 40 changes that came out of the BRM and you'll see what the final spec will look like.
that shouldn't be too hard.
@Rob Brown - For what it is worth, I have posted comments on this and Brian Jones' blogs and other Microsoft blogs which question or critique OOXML, and have never been blocked, which I greatly appreciate. I have also posted comments on Rob Weir's blog and Bob Sutor's blog which are either critical of ODF or supportive of OOXML in some facets (there are a few things about it I support), and have never been blocked there either, which I also appreciate. My biggest problem with this entire debate is the acrimony and contempt which the two sides tend to display towards each other. IBM is not the demonic manipulator it is portrayed as being, but neither is Microsoft. In whole, I think Microsoft has engaged in more dubious practices, but they also have a much larger stake in this than IBM. Those of us stuck in the middle trying to support both ODF and OOXML are often downright frustrated at how much more finger pointing there is than constructive work. Part of the reason I often promote Rob Weir is that he both puts in the hard work to demonstrate specific issues rather than spouting generalities, and that he works hard to make his posts accessible to people who may not be experts in the field. Many others on both sides of this debate want to turn it into a fight or grudge match. It needn't be that, and much of this would have been avoided if Microsoft had not made serious mistakes early on in underestimating both the effort involved in turning out an effective XML standard and in selling such a standard to the world. All too often, it becomes an "us good, they bad" finger pointing exercise, which both sides should be ashamed of.
(sorry for the long post)
Hi Ben… Regarding “Very convenient to then try to shut down those who are focusing on the issue, such as Rob Weir, because all the comments should have been made in the earlier 5 month period.” First, then why have deadlines for anything? Quite honestly, I found ample time to read through the spec, highlight my concerns with ECMA and MS, implement a part of the spec in an application I put together and all that was in addition to my day job. Second, it sure seems like Doug has outlined what to do (not “shut down”); your comments seem to support Doug’s point of view.
Hi Rob (Brown)… “These are not technical considerations!” What is not technical about two global organizations each writing code to spec for sharing content within a format? Have you seen an non-techy do this sort of thing? The purpose of having an international standard is to regulate interoperability between countries, is it not? Why would we not want to regulate the content stored in these formats? It seems like the first step would be to write it down (thanks, MS), then standardize it (thanks, ECMA), then internationalize it (thanks, ISO) then improve it (thanks to everyone who will participate in committees worldwide going forward). It seems like a weak point to make PDF, GIF, ODF, JPG, (many more) IS’s, but leave OOXML out seeing as MANY companies WILL use it… It seems like a very good point to say (just like the other IS’s), lets regulate this early on so that it doesn’t get out of control (which would mean, making it an IS)… wouldn’t you agree?
Hi Andre… “Is it true that you have been informed to stop responding on issues”; it gave me a chuckle when I read this, seeing as you are asking Doug if he has been informed to stop by commenting on something that he just posted; thank you, I needed a chuckle today :)… Regarding “The political debate, wheter there should be a second standard”, there is precedence for multiple IS standards. Saying this a political topic seems to prove Doug’s point, why are people making this a political topic when the reality is that this is very logical. It makes a lot of good sense to make this an IS. You know, I find it ironic that when I go talk to people who will store their content in OOXML; they seem delighted and in great support of having the format of this content regulated by the international community. But for some weird reason, the very people who they are relying on to regulate these standards seem to be letting them down by saying (and I am paraphrasing here) “we don’t want to regulate this content format as an IS”; or something like (again, paraphrasing), “well, if we just had more time, then we would agree that we should regulate this content format as an IS”. Can you please help me understand why you think that we should not regulate this format as early in the process as possible?
Hi Yoonkit… I have heard many great things about you and your abilities; however, I am struggling to see these reflected in your comments. What I see is procrastination (leaving this work to the last “2 days”); poor use of available information (an updated draft was made available) and misrepresentation (suggesting that you would have to go to so many sources of information, and implying that this was only made available to you today). Your comment here seems to be another great example of Doug’s point of view in this post. The reality is that MS, ECMA, the various NB’s along with many volunteers have done a better job at making information available for this DIS than almost any other (possibly all other) DIS’s in the history of the ISO; wouldn’t you agree?
Short of saying, “can’t we all get along here”; it would be great if some people could focus more on “how to make this an IS” (logical) than “why this shouldn’t be an IS” (political). (And no, Rob Weir, I am not suggesting that NB’s should never turn down a DIS; but, this is an obvious win/win for most companies worldwide)
Hope you are all having a super day!
Co-Founder & CTO
So coming into this I have to say that I was leaning towards the side of ODF. It seemed like it might be a logical approach, that Microsoft should have worked in OASIS, etc etc. But after reading these latest posts and comments, I know I was wrong.
Stephen, I have not heard or read any good things about Yoon Kit. This is because despite numerous searches on google, I can't find out who he is. So, despite being completely blown away by his comments and incredible lack of logic, I cannot find how he is qualified to comment on this issue at all.
So let me ask. Yoon, what experience have you had with software development at a level that has been beneficial to society (I don't even care about specific to Malaysia, just at all) in the slightest way? What is it that makes you qualified to comment on the technical merits of the specification?
I have read your blog, but it doesn't seem to be informational or attack the technical shortcomings of Open XML. While there are certainly still problems with the spec, to a smart reader it becomes apparent that you are much more comfortable in these tit for tat name calling matches that have NO TECHNICAL VALUE WHAT SO EVER.
Also, why have you not responded to Doug's request to post the deck you used? As an independent developer trying to make up my mind, I want to see this. If it's open, why can't I? Are you just ignoring this because it's convenient.
I think that one of the biggest mistakes Microsoft made in this course of events was legitimizing people who don't benefit open source, open standards, or technology in general.
Feel free to attack me Yoon, but as someone who was supporting this cause I am starting to wonder what the heck is going on here.
I agree almost totally with the comments you directed at me above! Not sure why you think I wouldn't. Perhaps you misinterpreted my comment, which was pointing out what I perceived as contradictions in Doug's post. I do think that interoperability, competition, data preservation etc are core issues in this debate; it seemed that Doug (with the sentence I quoted plus his step-by-step instructions to NBs) seems to be advising people ignore these things, and then changing tack at the end of his post.
My opposition to OOXML is about technical shortcomings in the spec, distrust of Microsoft's intentions, and disagreement over the need for multiple competing standards. These are simply my opinions and I don't expect anyone to share them.
ODF is not perfect, but I think it's a better starting point on the road to a great single standard, than OOXML is. If OOXML is approved as a standard, we'll be carrying its really crufty legacy artifacts around for years to come. Actually we'll be doing that whether or not it's approved ;-)
Your opinion in the "Process issues" section is that any NB choosing to alter their vote should be based only on changes that have been made to the DIS 29500 specification. This opinion does not match the commentary from SC34 in their pre-BRM FAQ at http://www.jtc1sc34.org/repository/0932.htm , which was highlighted by Alex Brown:
Q. 4.5 What if there is not time in the meeting to satisfy NBs’ concerns?
A. 4.5 If NBs find the outcome of the BRM inadequate then their recourse is to disapprove the DIS.
Q. 6.2 In what ways may an NB change its vote?
A. 6.2 NBs that voted in the 2 September ballot may change their vote from any of “approve”, “disapprove” or “abstain” to any of “approve”, “disapprove” or “abstain”.
Q: 6.7 What criteria may NBs use in deciding whether (or not) to switch their votes?
A: No constraints are placed upon the criteria NBs may use for deciding their voting position.
Based on this information, I do not believe that your assertions, which you emphasise by emotive phrases such as "To state the obvious", are correct.
Re-reading your posting after writing the above, I believe that this criticism can apply to other sections of your posting as well -- for example, you claim that technical defects found late in the process (post-September, or at least post-BRM) should be deferred to maintenance and should not be grounds for disapproving the DIS. I strongly disagree -- an approval is a significant commitment (since the standards environment partially shapes international relationships), and the onus is on each entity to find and use the best information available to it at that time.