The Perpuetual Ballot Resolution Meeting

by Rick Jelliffe

IBM/Lotus' Rob Weir has a timely blog up entitled How many defects remain in OOXML? Timely, because of course, the clock is ticking on the OOXML vote, so this is coming up to his last chance to throw some mud. This is a subject I am interested in, and have blogged on before, so I think it might be useful to make a comment.

The Set Up

First lets look at the set-up material:

DIS 29500, Office Open XML, was submitted for Fast Track review by Ecma as 6,045 page specification. (After the BRM, it is now longer, maybe 7,500 pages or so. We don't know for sure, since the post-BRM text is not yet available for inspection.)

Longer? Well what has happened is that
  1. Normative schemas (with structural improvements to run better on the open source XSD validators) that were in external files are now included in the text: there is no change in the amount of information in the standard despite the extra pages! In fact, because at the same time the schema fragments in the draft are now (post-BRM) informative, there has actually been an decrease in the amount of normative text.

  2. Non-normative material on accessibility has been added, again not requiring the kind of review of thought that normative text requires.

  3. Extra explanatory material requested by NBs has been added, but this text was specified in the Editor's responses or explicitly by the BRM, it simply isn't the case that NBs don't know what this text is: see the BRM outcome documents.

I have blogged before against the simplistic use of page length: That diagram (Let me ring your bell), and I refer interested readers to that.

Next, comes:

Based on the original 6,045 page length, a 5-month review by JTC1 NB's lead to 48 defect reports by NB's, reporting a total of 3,522 defects.

Now what you might not realize from this is that the 5-month review is actually a title or nickname for one phase of the review, not the actual time limit. The initial text was released in December 2006, and national bodies didn't actually submit their ballots until September 2007. So National Bodies had 9 months, not 5. (And interested parties could have participated for the prior year-long process at ECMA, which included a public draft.)

The total of 3,422 defects sounds impressive, except that most of them were duplicates, many just cut-and-paste duplicates by lazy or novice reviewers who somehow were under the misapprehension that in ISO process the squeaky wheels would get the most oil. ECMA grouped them into 1027 unique issues, however my estimate was that many more could be grouped together (this is borne out by the repetition of answers within the Editor's disposition of comment) to about 750 really unique issues.

Next comes the material on a defect count per page. (To give an idea of why this is an area where simplistic use of numbers will be actively misleading is, of course, that adding the extra pages of schema material will actually cause a reduction in average the number of errors per page, without decreasing the absolute number of problems.)

I have blogged before On error rates in drafts of standards and I refer interested readers to that. Note that I give an estimate of the number of errors that your would expect to be caught (in one pass) at about 1,000, which was exactly what we have. In particular, note (ISO SQL Editor's) Jim Melton's comments, which I will repeat

Or perhaps most people were somewhat intimidated by the prospect of (thoroughly) reviewing a 6,000 page document. To put this in perspective for those who know SQL’s size and complexity, the sum of all nine parts of SQL is about 3950 pages. A ballot on SQL frequently receives several thousand comments, and we’ve been balloting versions of SQL for 20 years!

In fact, virtually every large spec I’ve ever had the “pleasure” to review leads to “thread-pulling”, in which every page yields at least “one more” bug, and following up on that one leads to more, and following up on those leads to still more, etc. I would personally be stunned if 30 dedicated, knowledgeable reviewers of a 6,000 page spec on its first public review were unable to find at least 3,000 unique significant problems and at least 40,000 minor and editorial problems. But that’s just me…

Under that kind of criteria that our Big Blue friend is proposing, the ISO SQL standard which is one of the most widely implemented and important and mission-critical of all ISO IT standards would not be of high enough quality to make the grade! Next Mr Weir says:

If we believed that the 5-month review represented a complete review of the text of DIS 29500, by those with relevant subject matter expertise, then we would have some confidence that all, or at least most, defects were detected, reported and repaired.

Did you see the sleight-of-hand there? The outcome "repaired" is not the only possible outcome! The big possibility that Wier misses is that a defect can be allocated to maintenance: the ballot to become a standard is not the end of the process but merely the start! But absolutely no reference to this. Why? To panic people into assuming this is the last and only chance to get things perfect.

(Weir does have another post Contra Durusau, notable for a really sleazy reference to Seattle. He takes an unrelenting anti-maintenance line, rather surprising in the light that the same arguments can apply to ODF which is his alternative. It does not suit his argument that there are many standards with successful maintenance.)

The Trick

One of the constant themes over the last year has been the theme of panic. QUICK: You only have one month to find contradictions. QUICK: You only have five months to find defects. You only have a few weeks to evaluate the Editor's comments. Every person has to read or review the whole standard. Every national body needs to have an explicit detailed position on every issue. And so on. Always under the assumption that the current stage is the last and only chance for change.

It every case this panic is has been unnecessary FUD-mongering, because at ISO there is always the scope for improving a standard. [The normal caveat that you want to get it as right as possible first time because you cannot bolt the stable door once the horse has bolted does not apply with the same strength as with a from-scratch standard because the horse has already bolted. In fact the horse has been off and running for the last 20 years! So "getting it right" relates to documentations and harmonization rather than the general shape.]

What happens when a draft gets accepted as a standard? It gets subjected to the normal committee maintenance procedures. There is indeed a special step which can be taken where a standard gets deemed stabilized and so not subject to maintenance, but there is absolutely no way that IS29500 (or IS26300) are candidates for that yet!

Maintenance sounds a dreary word, but what it means is that National Bodies (and liaison bodies) can submit to SC34 defect reports. And I would hope there are a backlog of these issues: a trouble with a stretched out Fast-track such as we have had is that it means there is in effect six months where Defect Reports have to sit on the shelf waiting until the standard is accepted before being processed. That there have been more defects or improvements discovered since the ballot was taken is not a source of wonder or horror: of course there will be more issues discovered: how could it be otherwise?

But it is a complete mistake, and at worst disinformation, to think that defects remain outstanding, that the standard is set in stone at the time of voting. Indeed, ISO ODF is largely predicated on there being ongoing maintenance to fill in the gaps and fix problems that are found. The thing is that standards based on deployed technologies do not need reviews based on "is this technology bogus and unimplementable" in the way that blue-sky standards do: in the case of Open XML and ODF and PDF you can open up a file and look at it and see whether the big and middle picture is workable. (And you can go further and validate the XML with the schemas, for fine-grained and objective compliance testing, of course.)

At ISO/IEC JTC1, the rule is that the Editor has to handle defect reports "promptly". ("Promptly" needs to be measured in quarters of years, it won't be weeks. But it won't be years or decades, which is how long some bugs have persisted in Office without the circuit-breaking of National Body scrutiny.) SC34 participants have been discussing many issues relating to getting maintenance agile and pro-active, and National Bodies who are interested in document standards need to get involved.

What you have in the ISO process is equivalent, if the NBs want it, to a Ballot Resolution Meeting every six months in perpetuity. Defect Reports can include detailed suggestions for change, and it is even possible to bundle them as Draft Amendments and get that fast-tracked.

There is a lot of talk about "ECMA should resubmit it for another fast-track" or "ECMA should resubmit it for slow-track" and so on. I regard a lot of this talk as disingenuous, because it is frequently suggested by commentators who you know are not interested in corralling OOXML into a standard no matter how technically excellent it can become. It looks like a compromise but it is intended to block progress not help it. Now I have no general objection to standards taking years to complete, but for a deployed technology the correct process is the maintenance process not the committee draft process.

Every standard that gets adequate review will have reams of defects reported. That is just as much a function of the intensity of review as the underlying quality of the standard. Indeed, you could use a reverse metric: any standard which does not have at least one defect per 6 pages reported (for example) should be suspected of having inadequate review. DIS 29500 has had thousands of people reading it and reviewing it. Thousands, not hundreds. A big swathe have been dealt with, a big swathe has been dealt with partially and can be improved further; and there is a big swathe of issues that are not defects at all but extra features which clearly belong to maintenance not initial review.

But the idea that this is it, this is Microsoft's only accountability moment where they get a pass or fail is propaganda, not the ISO process. It is completely true that the maintenance procedure needs continued interest and continued pressure, but it is not true that this is the last chance to improve the standard as if it will be frozen for all time.


In comments below, ISO SQL editor Jim Melton has clarified his comments. I was glad to see him say Please note also that I have taken no position at all on the merits of standardizing the technology in the spec, nor even the merits of the technology itself. What Jim says, however, is that he would expect a full multi-year review of a new 6,000 page spec to almost certainly reveal upwards of 5000 unique issues.

I have three responses to that. First, that Ecma 376 already had a year of review before ISO, so it is inappropriate to count the number of issues as from a de novo standard: we should be open to the possibility that in fact we did not find thousands more problems because they are not there. (However, Jim's original comment about pulling threads is really appropriate.)

Second, that the error rates in a standard have to be tied to the number of normative pages not just the raw page count: OOXML is unusual as a standard in having so much repeated and non-normative material: indeed, Patrick Durusau in 20 hours was able to condense the WordProcessingML material by 74% to 452 pages: assuming that the other parts have similar rates that gives us about 1500 normative pages, which by Jim's metric should reveal only 1250 unique issues. Compare this to the approx 1,000 issues that were dealt with (and the large number of issues dealt with en masse such as fixing ISO-ese shalls and shoulds and fixing examples) and the review is actually looking pretty good even on Jim's metrics, isn't it!

And my third point is the same one I have said elsewhere. The maintenance process is the best place to deal with remaining issues. If you look at some of the FUD lists floating around of new issues, you see an indiscriminant grab-bag of new feature requests, denials of the scope of OOXML which emphasizes legacy features, function changes, as well as (hopefully) some errors proper. These are not showstoppers, but they all should be dealt with sooner rather than later because of their importance. And sooner means by maintenance of the standard, not by pre-standardization faffing around and fillibistering.

Update 2

A website picked up on this exchange and quoted Jim's
You've written 6000 pages of specification largely in secret (and, I understand, recently added over 1500 more pages) and given the world five months to read, absorb, understand, review, critique, and establish informed positions on it.

So I think it is useful to restate the problems with this.

  • 6,000 pages The pre-BRM draft standard (DIS 29500 mark I) had over 6,000 page plus several hundred more for schema files that were not printed in the text. However, the text of a standard has normative parts which state actual requirements and informative parts which give extra information to help users. Estimates from the editor of a "rival" standard is that about 75% of the content of DIS 29500 mark I was informative or could be condensed to that without loss. The additional pages (and I have seen no reliable count that it is 15000 pages: that seems just puff) is mainly due to taking schemas that currently are normative and putting them into the standard; however, at the same time repeated fragments of schemas in the draft text are being made informative, so actually there is net decrease in informative material.

    So really what we have is a standard of about 1500 normative pages (perhaps 2,000 pages including schemas) with about 4500 pages of additional information to help explain it. The attempts to use the blanket figure 6000 disguise both that the text has an enormous amount of material to aid understanding but also to allow inflated views of the amount of work needed to find errors in the normative sections. Furthermore, there is an enormous amount of repetition, so review comments from one section often applies without change to other sections.

  • Secret Actually, Ecma put out a public draft for comment.

  • Five months No, the "five month period" is the nick name, and it actually took nine months until the ballot. So not 5 months to review 6,000 normative pages, but 9 months to review effectively 1,500 normative pages. What is the difference: well let us remove 1 month for administrative palava, the difference is 6,000/4 = 1500 pages per month and 1,500/8 = 187 pages per month.

  • Five months No, actually there was an additional period after the ballot where National Bodies could look at each other's comments and participate in the Ballot Resolution Meeting: which takes it to over a year in total, not including the previous year of development at Ecma

  • read, absorb, understand, review, critique, and establish informed positions But every individual National Body does not need to have a definite opinion on each individual issue: abstain is fine on issues that are not of interest or are outside the expertise. I don't know how the ISO SQL Steering Committee works, but in SC34 national bodies try hard not to act outside their competence and are careful to abstain rather than spoil the process: they find the best experts they can and encourage development of national expertise and awareness of their particular national interests: Japan on internationalization, fonts and formal schemas for example. The review happens not because everyone involved knows everything, but because collectively and cooperatively all the issues get adequate coverage. For example, there may only be three or four National Bodies with deep experts on maths, and several more with general experts who can get the drift pretty well, and a few more with industry contacts and other liaisons, and that is more than adequate for review.

  • Given the world SC34 has been operational in one form or another for almost 25 years. People who are interested in this area have had a long time to get involved, learn the procedures, get national committees going, participate in various standards to learn the ropes and make networks. Both when ODF and OOXML were first proposed for fast-tracking there were good signs for people who were interested to get involved. The idea that somehow DIS 29500 has been foisted on an unsuspecting and unready public shifts the responsibility away from the people who should have been participating and up-to-speed. If a National Body (or government or other stakeholder) ignores developing skills and experts who will be ready to participate when the time comes, of course they will not have enough time: but it is their fault! If you are running in a race, arrive late, and the starter's gun goes off while you are still putting on your shoes, you cannot complain "I didn't have enough time!"


2008-03-19 07:07:29
yes, i like your approach Rick

Free and easy ISO fast-tracking for everything and everyone! ( who can afford to staff committees and upgrade countries to P-member status )

Go ahead, happy hour at ISO !

2008-03-19 09:06:10
Did you read the comments below Rob Weir's article?

It is easy to calculate that from this sample we can estimate the number of technical (not editorial) errors in DIS29500 at over 15,000, not 3,000. Many of the reported errors foil implementation of the standard.

This will take years to sort out. Not just "wait for SP1".

Especially as Ecma did not show any inclination to really REMOVE problems from DIS29500, but added just more options to taper over the existing deficiencies (we have now 5 date formats in DIS29500, including the initial 2 or so).

And we still have NO mapping between the older binary formats and DIS29500. Which was the whole reason for the exercise, wasn't it?


2008-03-19 10:50:08
>>>because at ISO there is always the scope for improving a standard

This is exactly what people are worried about, if we do not stop the insanity of OOXML, Microsoft will take the word "ISO Standard MSOOXML" and change it to be in-compatible with any implementation that is non-microsoft. ( Embrace, Extend, Extinguish).

Microsoft has thoroughly disgraced itself with this push to create a standard when a thoroughly capable standard called ODF already exists, but Microsoft does not want to play on an even field.

2008-03-19 11:23:04
After reading this, I have come to the conclusion that either 1)you are a Microsoft fanboy or 2) have been paid to post this.

How can MSOOXML be an industry standard when some of the formats MSOOXML points to is only accessible by Microsoft? How can MSOOXML be considered a standard when the Promise Microsoft puts out with it is incompatible with some of the other licenses the computing industry uses? How is MSOOXML going to be any different in its usage than other formats Microsoft has used in the past to destroy other competing formats? Consider the ongoing NovelvsMicrosoft antitrust case.

You indicate that Rob Weir is, in your words, using "sleight-of-hand" to change the meaning of facts.

With all the evidence that is on the internet, its my opinion that it is you, Rick, that is using "sleight-of-hand" in your writing to produce FUD and to drag Rob's name through the mud by trying to discredit his blog.

Rick Jelliffe
2008-03-19 21:33:22
omz: Are you saying that defects don't or cannot get dealt with by maintenance? In that case, why allow any technology as a standard?

winter: I will be looking at the individual items in more detail. Certainly if you want to treat new functionality as an issue, there is no end to the amount of issues that can be raised. Why not 10,000 issues? Why not 1,000,000 issues? But being issue-free is not the criteria for becoming a standard, because there are always new issues coming up.

Kevin: The benefits of a monoculture is a different issue than sky-is-falling arguments about remaining issues. I don't see that MS has disgraced itself at all: they are doing exactly what many of us have been hoping for and requesting for years: see Slashdotters : all together now Doh! for example.

If you are wanting to identify disgrace, what about a delegation to an ISO meeting that votes against the clear resolution of issues it raised itself? What about a delegation that voted against resolution of issues that other national bodies had raised, but not on any technical grounds?

Randy: There is no need for me to drag anyone's name through the mud when they can do it perfectly adequately themselves. I am not a particular fanboy of Microsoft in general and I am not paid for anything in this blog (and I am not aware that they are on our books for any current jobs, though I am not aware of all the jobs by companies I consult for.) However, I do believe that All Interface Technologies by Market Dominators should be QA-ed, RAND-z Standards! and that Corporations who were market leaders in the 1980s and 1990s for PC applications have a responsibility to make sure that documentation on their old formats are not lost and so should submit their formats (text, binary, media) to ISO as Technical Specifications.

Joel Stobart
2008-03-20 02:05:03
Ok Rick - Standards are what we build our houses with. What we use to make our cars crumple safely in accidents. Standards are the framework for everything else that you build on top. You don't really want your standards to be stupid, or worse wrong.

So it is important that standards are solid, and reliable. Not that they are perfect; just that when I make something with them and you make something with them those things have similar components.

Deliberately Ignored problems.
Lots of mistakes in the specification were deliberately ignored as they broke "legacy" issues. This is version 1 of the standard, and office 2007 has only started making documents 1 year ago. What legacy? I for one would rather see a well written, modular, design-led independent specification than one that is intrinsically allied to a particular vendors existing corpus.

One sensible way of doing something:
As I understand it OOXML provides 5 ways of doing dates, 2 ways of drawing a box, 5 ways of changing a font. why?

As I understand it there are numerous ways to introduce anomalous binary application-specific information into a document. This sounds like heaven to any virus writers.

Why Bother
This process is using thousands and thousands of man-hours. All to introduce a second, competing standard for documents. Why not spend the time honing and improving the original standard so that it is really really brilliant?

Vendor Safety and Bad at accurate standards implementation
Microsoft have previous. I live in Europe; here, Microsoft are known to have cut up the opposition. They have the largest fine in European history for doing it. As you are standards man, I am sure you will have read the complaint by Opera, and if you are like me, agree with almost every word. I will also refer you to MS Java implementation.

If its so compelling?
If the standard is so compelling why did the NBs vote it down last time? Why do Microsoft keep committee stuffing? paying partners to vote? asking NGOs to write letters in return for cash? Write reputation damaging letters to government departments? pay people to update Wikipedia? Force abstentions in countries that have a consensus? If someone tried to make me vote for them whilst I watched them ballot-stuffing I think I might just vote the other way?

2008-03-20 04:28:22
You write
"A ballot on SQL frequently receives several thousand comments, and we’ve been balloting versions of SQL for 20 years!"
This merely shows that a standard of several thousand pages cannot succesfully cleaned up in a few months. And from everything I've read in other places, OOXML needs clearing up.
But if the fast track is dropped and ISO takes the time to do it right, OOXML may become a usable and well respected standard eventually. 20 years from now maybe?
Rick Jelliffe
2008-03-20 05:14:55
Martin: I would expect that in 20 years time, we will be using some other standard that has been the fruit of cross-pollenating ODF, OOXML, W3C specs, PDF and so on.

There will be a big bunfight because IBGoogadobappleBay will be fighting that their standard markup language for indexing brain neurones (with the snappy slogan "Trust us: we know everything anyway!") is incompatible with DNA knowledge insertion markup language from MicroSoft (with the snappy slogan: Embrace and Extend your DNA! or What mutation do you want to have today!) ISO will be involved in fraught attempts to have one side's aluminium brain helmet adopted rather than the other's, and accusations will be flying.

Jim Melton
2008-03-20 08:44:56
Whoa, there, Rick. If you're going to quote me, then I want to be sure that the context is available to your readers.

One relatively important fact that didn't show up in the words you quoted is that the standardizers of SQL weren't so arrogant that we thought we could rush (and it's hard to deny that the phrase "Fast Track" implies hurry) 6,000 pages in one go, without it having not been visible to the vast, vast majority of the world until it started its FINAL ballot.

So, it took the SQL world some 20 years to write 4000 pages of standard, to root out the serious bugs (and thousands of smaller, mostly editorial, bugs at the same time), and to reach a genuine consensus on the content. I don't know Rob Weir, but I think it's misleading and unfair to extend what he said by concluding that SQL is not of sufficient quality to "make the grade". I do not believe that anybody thinks that there are still 200 serious errors remaining in SQL's 4000 pages, must less a thousand or two. Why? Simply because we have taken the time...years of carefully root them out and fix them, giving the world at large plenty of time to review our bug-fixing efforts.

What I see DIS29500 doing is exactly the opposite. You've written 6000 pages of specification largely in secret (and, I understand, recently added over 1500 more pages) and given the world five months to read, absorb, understand, review, critique, and establish informed positions on it. Worse, whether it happened because of unreasonable methods, pure random chance, or genuine and unexpected interest, the fact that the size of the JTC 1 Subcommittee that was to vote on the document suddenly exploded gives the appearance that somebody was trying too hard to stack the deck...almost as though it wasn't really desired to have too much real review. Please note, I don't know any facts at all about the membership changes in SC 34, except that it happened. I'm not accusing anybody of anything, merely stating what people have inferred from those facts.

In my not-so-limited experience, if a 5-month (or 9-month) review of a 6000 page spec revealed "1027 unique issues", then a truly open process in which the document went through the normal WD, CD, DIS, FDIS process would almost certainly reveal upwards of 5000 unique issues. Also in my experience, fixing even 1000 non-trivial bugs is a very daunting process that takes many months, perhaps two or three years (given a reasonably high frequency of meetings -- say, three 3-week meetings per year).

In short, I want to emphasize that I think a Fast-Track process for any standard of this magnitude is a monumental mistake and a serious perversion of the entire concept. I was wary of that process when it was introduced, but saw that (initially, at least) it was being used for moving well-established, very widely implemented specifications into the ISO world for maintenance and possible additional development. Speaking solely for myself (and I EXPLICITLY disclaim any intent to imply an Oracle viewpoint, a USA viewpoint, or a North American continent viewpoint!), I find the whole thing appalling.


P.S., Please note also that I have taken no position at all on the merits of standardizing the technology in the spec, nor even the merits of the technology itself. I am ambivalent about whether the world community would be better served by one standard in this space or two or more (I know that the world is a Better Place for having one standard for relational database management, and a Better Place for having more than one standard for programming languages). I object solely to the process by which this has taken place.

P.P.S., Again, without making accusations about anything, are you aware that the international standards community generally views ECMA now as a wholly-owned Microsoft subsidiary? I offer no opinion about the validity of that view, but almost everybody to whom I have talked about ECMA dismisses it as little more than Microsoft's bought-and-paid-for channel for submitting documents for pretend standardization. That sounds a bit harsh, but that's what I hear.

P.P.P.S., One last thought and I promise I'll close: You refer in your text to "IS29500". That's rather premature, isn't it? At the time of my writing this response, the standard has not been ratified. So it's still DIS 29500 at the moment.

Arnaud Le Hors
2008-03-20 13:32:04
"There is no need for me to drag anyone's name through the mud when they can do it perfectly adequately themselves"

You're at least right about that and you keep demonstrating it every time you post on this subject. :-)

In case you didn't realize, let me tell you that you've seriously damaged your image among standards experts and for someone used to the W3C's standard process and its ever more stringent process to produce higher quality standards, it is simply unbelievable that you would, in all honesty, make the claims you make about OOXML's quality and the appropriateness of the Fast Track process for this monster.

And, please, explain why the world should ratified what wouldn't even qualify as a public Working Draft in W3C as an ISO standard before it gets cleaned up rather than after?

Don't tell me it's because it's the only way to have Microsoft participates. Microsoft never sticks to any standards, it won't care about sticking to this one any more than any other. They just want the label.

Good luck with the fallouts.

2008-03-20 14:16:07
Gee, Rick, if we don't need to worry about the defects in a proposed standard because they can always be resolved later, then shouldn't the ISO just accept anything proposed to it, without any standards it has to meet or any process of evaluation and improvement before it is accepted?
Adriano Varoli Piazza
2008-03-20 16:03:10
Good work! Equating a standard that took years to come to be to another rushed to fast-track is certainly going to convince me!

Arguing how a big lot of bugs is really only a significant amount of bugs is certainly going to convince me!

"the 5-month review is actually a title or nickname for one phase of the review, not the actual time limit". Sure. And Bush's and Gore's time to check votes on that year's election was also just "not the actual time limit". True, but guess exactly what amount of time was considered?

"One of the constant themes over the last year has been the theme of panic.[...]Always under the assumption that the current stage is the last and only chance for change."
It actually is. Once Microsoft has this standard under their belt, they can do whatever they want with it. That's the advantage that having what is arguably the only office suite that renders the "standard" while being backwards compatible gets you. For an example, if Mozilla Firefox and Thunderbird hadn't started eroding their dominance on the web, even more years would have passed without significant improvements to IE (what was it, 5 years?). Thus it's of the essence that people correct them ASAP.

Seriously, I try not to dislike Microsoft, I try to be professional, but they make it _so_ _damn_ _hard_...

Glen Turner
2008-03-21 00:16:59

Companies are going to have to implement this specification as-written. To achieve legal protection under the limited patent license offered by Microsoft companies are going to need to show traceability of program code to DIS29500 clauses. (This need for traceability the major practical distinction between Microsoft's OSP and more traditional patent pool license).

Pushing a large number of specification errors to maintenance plays hell with any thoughts of a reasonable time-to-market for a .DOCX feature which is legally safe.

It places companies in the invidious position of needing to work beyond the protection of the patent license for DIS29500 and achieve interoperability by reverse-engineering the OOXML produced and accepted by Microsoft's products.

Cheers, Glen

Glen Turner
2008-03-21 00:34:16
Rick: However, I do believe that All Interface Technologies by Market Dominators should be QA-ed, RAND-z Standards! and that Corporations who were market leaders in the 1980s and 1990s for PC applications have a responsibility to make sure that documentation on their old formats are not lost and so should submit their formats (text, binary, media) to ISO as Technical Specifications.

Hi Rick,

When the IETF was faced with this issue it drew a distinction between RFCs which were Informative (such as the specification for the then-widely-used SLIP protocol) and RFCs which were Standards Track (such as the IETF's PPP protocol, which it preferred over SLIP).

I don't believe there is a similar distinction between ISO standards, making ISO the wrong forum for specifying non-preferred protocols (and what are document formats but protocols using disk rather than network).

Not that I disagree with your aim -- I'm writing a PC Write filter to retrieve some old books my publisher wants to re-issue and reverse-engineering just hurts even for such simple documents. A decent specification would be gold. ISO just isn't the organisation where that specification should reside.

Cheers, Glen

Tsu Dho Nimh
2008-03-21 12:12:55
"Every standard that gets adequate review will have reams of defects reported."

Yes, but unlike the OOXML standard, they are usually found and fixed before the standard is up for voting.

Microsoft is knowingly pushing the world+dog to release a standard that has egregious errors that prevent its being implemented as written - let alone written to work. What Microsoft proposes ... "address it in maintenance" ... is the equivalent of an auto dealer saying, "I know the motor misfires, the muffler is dragging, and you are missing two tires, but we'll fix it when you come in for your 60,000 mile servicing."

I am not qualified to comment on the technical quality, but the text of the standard is so poorly written in many places that it is impossible to discern the intent of the paragrpah. I'm a technical writer and editor. I am accustomed to working with documents from engineers and programmers whose native language was not English, and this standard is close to the worst I have ever seen. The haste with which it was created by chop-and-drop editing from documents that do not seem to themselves have been edited is clear. It's dogs-vomit on paper!

Gareth Horton
2008-03-21 13:45:39
@Jim Melton - "almost everybody to whom I have talked about ECMA dismisses it as little more than Microsoft's bought-and-paid-for channel for submitting documents for pretend standardization"

I suppose you might get that impression when talking to your colleagues at Oracle and IBM.

And everyone I have ever talked to says dismisses OASIS as little more than IBM/Sun/Oracle's bought-and-paid-for channel for submitting documents for pretend standardization.

And everyone I talk to at the "Rick Jelliffe Appreciation Society" (no, I don't think it exists yet Rick - don't get too excited) thinks Rick is right.

It all depends who you talk to and who your friends are, it doesn't guarantee an accurate picture.

This has become an arms race, started by Sun and IBM with Oracle and now Google as willing henchmen. As a rational business entity, Microsoft has to participate in this race too.

If that's not a picture you recognize, then I suggest you go back and do a little more of your own research.

It seems like precious few are capable of doing any of their own research around here, regurgitating the anti-ooxml party line like drones.

The specification was publicly available for quite a long time, certainly longer than the 5 or 9 months we are talking about here.

I know this, since we worked from the ECMA specs to implement Open XML read and write functionality for spreadsheets, in a commercial product we RELEASED in February 2007 (There's 12 months plus for you). Our product is used in over 20,000 organizations and has been in the market since 1991, so this is not some fly-by-night, never to be released project on a web site somewhere.

Jim, this is not directed at you, since you at least have experience with the standards process, but it seems like there are endless armchair experts out there, pontificating on issues they have absolutely no idea about.

As for the chap that said ODF was a "thoroughly capable" standard - not from our point of view as a commercial software company with a particular focus on spreadsheets. Heaven help a company trying to actually implement a fully-fledged spreadsheet app.

If anyone mentions the "Microsoft should help to improve ODF and make it functional enough to mirror OOXML" - why not have wheeled out the ANSI text spec and polished that up a bit instead of all that Unicode nonsense.

As regards defects and release behavior, then if Rob adheres to this methodology, then the first version of Notes should have been in the final QA cycle by around 2140. Maybe I'll leave instructions with my offspring to intermittently lodge a bug report or an enhancement request so that it is never released at all.


2008-03-21 19:45:56
And why is it that one needs OOXML now?
How many maintenance releases of a standard need there to be until a V1.0 is accomplished, so that there not be any more *Various xslx Export bugs fixed* as a result of inconsistencies or an incomplete documentation.
As of now it seems rather like a beta product with a promise to fix it later. Thanks, but no thanks.
Also, wouldn't it be wise to remove a lot of the redundant "xml", so that 1 markup rules them all (if possible), as seen in "The Disharmony of OOXML" . Wouldn't especially ISVs with limited manpower profit from this?
Well, maybe not the ones with 20 years of experience of reverse engineering Microsoftspeek/-binary.

A standard now at the expense of excessive complexity for the foreseeable future. Let me think about it...

2008-03-22 22:55:52
Hello everybody, my name is Damion, and I'm glad to join your conmunity,
and wish to assit as far as possible.
Jim Melton
2008-03-23 16:53:54
Gareth Horton said:

@Jim Melton - "almost everybody to whom I have talked about ECMA dismisses it as little more than Microsoft's bought-and-paid-for channel for submitting documents for pretend standardization"

I suppose you might get that impression when talking to your colleagues at Oracle and IBM.

Cute response, but irrelevant. I don't talk to my colleagues at Oracle and IBM about this subject, 'cause it isn't part of my day job -- I have enough to do without even asking whether we have a position, never mind caring what that position is!

"almost everybody to whom I have talked about ECMA" are people in the standards arena, and not just ISO, not just W3C. It might not be surprising that Microsoft went to ECMA, because ECMA (last time I checked) was the only Class A liaison with ISO (Class A liaison organizations have unusually great power for submission of documents for standardization). ECMA has long ceased being the "European Computer Manufacturer's Association", but for a while it seemed to care about actually developing standards and submitting them for fast-track processing.

Unfortunately, it now appears to most outside observers (e.g., those of us in many ISO Technical Committees and Subcommittees) that ECMA now serves merely as a conduit for Microsoft specs which wouldn't stand a chance in an ANSI technical committee.

You can wave the flag all you want to, muddy the water saying negative things about other organizations, etc. But that does not change the fact that Microsoft has handled this subject very badly and with an extremely heavy hand, nor that the international standardization process itself has been significantly damaged by the whole sordid affair.

(By the way, I have no opinion at all about OASIS 'cause I don't know enough to have an educated opinion -- and I try not to develop opinions until I have some information.)


Rick Jelliffe
2008-03-24 00:33:02
Jim: Of course I think bugs should be fixed! The issue is the forum: because OOXML is clearly at a level where maintenance can begin (with the big picture issues sorted out, the little-picture issues at a good stage, and hundreds of middle-picture issues fixed), going through a rigorous SC34 maintenance process is the optimal way ahead.

By the way, OOXML was not developed in secret, there was a public draft and review period at ECMA before it went to ISO. (Indeed, some of the source material had been available for more than a decade as MS documentation!) Then at ISO we have had 9 months of review time, and more than a year until now.

I don't see the logic in National Bodies which merely parroted material from another source, rather than doing their own independent review, now saying "Oh, there are more problems". I feel like saying "Of course there are, and you chose not to find them!" It smacks of disingenuousness.

And I would certainly hope that there are diminishing numbers of issues that could be caught over time: how could it be otherwise? However, your quote says what it says, Jim: there are often large numbers of issues outstanding.

The point of my argument is that the DIS29500 mark II draft is easily at a good enough stage where these fixes can be done through maintenance. (If OOXML is not at a good enough stage, then neither was ISO ODF: have you actually read it? I am sure ODF 1.2 will be a significant improvement.) In the case of ODF, the NBs clearly established that an incremental standard was a fine approach, and I think it is a double standard to make a requirement of one technology that is not required of another. People talk about ISO's reputation and standing, but the requirement for fairness, equal treatment and, ultimately, the need for the standards process to provide a continuing forum for mediation and improvement is *just as strong* as any other consideration.

This has always been my view: in Seoul in 2006 I remember saying "If Sun can have their standard, I don't know why Microsoft cannot have theirs". Not in the sense that Sun or Microsoft then own the standard afterwards, or that they should always get what they want (far from it!) but in the sense that fairness and equal treatment in ISO are so important that if there are not there, there is no justification for any voluntary technical standards.

Standardization processes that are not based on a level playing-field are cartels: the don't create markets, they prevent them. They are a conspiracy against the public. The people who huff and puff about ISO's reputation and yet want OOXML stopped not on any technical reason but because it comes out of MS are in fact hellbent on destroying ISO's reputation and ability to function. Because *without the level playing field, no standards organization can justify itself under anti-trust consideration.*

Rick Jelliffe
2008-03-24 01:03:49
Arnaud: You wrote

In case you didn't realize, let me tell you that you've seriously damaged your image among standards experts and for someone used to the W3C's standard process and its ever more stringent process to produce higher quality standards, it is simply unbelievable that you would, in all honesty, make the claims you make about OOXML's quality and the appropriateness of the Fast Track process for this monster.

Well Arnaud, it is I who am disappointed in you. "In all honesty": how slimy!

Arnaud, you manage IBM standards, and yet you want standards organizations to exclude your competitor: so much for a commitment to standards unless they are convenient for your organization... The argument that MS should never be given a chance to do the right thing again because it has not done the right thing in the past is bogus beyond belief: you are saying that MS should never be *allowed* to do the right thing! Your line is beyond a joke.

And you are happy to talk about "image" and spread this FUD about someone for daring to disagree with you: so much for a commitment to openness unless it is convenient for your organization... Openness requires that the forum allows different voices, that inconvenient opinions get aired and that majorities cannot gang up on minorities. If you are warning me off for daring to have a different opinion, then you have little actual commitment to real openness.

Do you know what I have seen in W3C, time and time again, Arnaud? I have seen the big companies form effective voting blocks and blocking off the requirements of other members. The W3C does produce many excellent standards, but only from those groups where competitive urge is suitably suppressed. The W3C methodology is very good for producing recommended technologies, but it has absolutely no credibility for producing exclusive standards or standards that are necessarily appropriate outside the WWW. That is not the W3C's mission nor how it speaks of its own "recommendations".

What IBM is freaked out about is that it is finding the ISO process so difficult to dominate, unlike the W3C. Hence this resorting to warning off people who have different opinions. This desperate last-minute attempt to swamp people with bogus procedural minutae, this warning off and disparaging of inconvenient dissenters.

It is a *different opinion* on a file format, Arnaud. It is not Dafur. It is not poverty. It is not HIV. It is not desertification. It is not genetically modified crops. It is no abortion. It is a different opinion.

In all honesty, Arnaud, anyone who thinks less of my for having a different opinion to them is not someone whose opinion I care about. Indeed, I would be more likely to consider it a badge of honour. (Especially if that person was from a large corporation which had showed itself to have no actual commitment to standards it could not control. Where has IBM been at SC34 the last decade?)

So Arnaud, please let me return the warning, but in a spirit of friendship. You and Bob Sutor (and IBM, because of the positions you two hold as spokesmen for them) have severely damaged *your* images among standards experts of all hues. Your side has dropped hints which have been obvious to your readers, have been taken up and amplified by your readers, and which your side has then linked to approvingly, to create suspicion about the motives of people who disagree with you. You, Bob Weir and most of all Bob Sutor as the responsible executive, owe a public apology and a disavowal of this slur campaign.

I urge anyone feeling intimidated to get even, but not by sinking to the level of personal invective. Boycott IBM. (Boycott Microsoft too, I don't care!) Vote to accept DIS29500 mark II and participate at SC34, OASIS, W3C and ECMA of all these related standards. Don't be a passive bystander, lost in this sea of rubbish and FUD and innuendo, get involved!

Rick Jelliffe
2008-03-24 22:53:36
Jim #2: Would you like to elaborate on your claim that "ECMA now serves merely as a conduit for Microsoft specs which wouldn't stand a chance in an ANSI technical committee"?

A cursory glance at the ECMA home page reveals that they are actively involved in a lot of activity in diverse areas:

C# (Chairman from Microsoft)

ECMAScript (Chairman from Mozilla)

Business Communications (Chairman from Siemens)

Near Field Communications (Chairman from Sony)

High Rate Short Range Wireless Communications (Chairman from Sony)

Environmental Design Considerations (Chairman from IBM)

Accoustics (Chairman from HP)

Electromagnetic Compatibility (Chairman from Intel)

Optical disks and disk cartridges (Chairman from Toshiba)

Universal 3D (I3D) (Chairman from Boeing)

Holographic Information Systems (Chairman from Fujifilm)

OOXML (Chairman from Microsoft)

XPS (Chairman from Global Graphics)

ECMA was the institution that Sun went through in its aborted efforts to standardize Java: it was reported at the time that Sun withdrew from the standardization to start its own process because it would lose too much control at ECMA

So ECMA is clearly not so much of a rubber-stamping organization that it didn't freak Sun out. And it is clearly interested in more things than Microsoft derived specs.

So what do you mean, Jim? I apologize of you are getting pressure from your bosses for pointing out things that are inconvenient to them, by the way.

But your answer does not make much sense to me. You say that large standards require a lot of review, and that it is easy to find errors in the early reviews: I would hope that after 20 years OOXML would have as few issues as you estimate are now in ISO SQL. However, ISO SQL got to where it is by years of diligent maintenance and review, not by any requirement that review would not find any more issues, was it?

The fast-track processes loads this review to the later stages, however it is not correct that OOXML by-passed the committee draft stage and went direct to draft: it went though drafting stage at ECMA, and different organizations simply have different emphasises(?).

2008-03-24 23:01:24

Each time I read you, I get more to the conclusion that you're paid off by Microsoft.

Before, you at least were sticking to technical arguments on the standard, but now you started making it political. If your arguments didn't sustain themselves before, now they are just a laughingstock.

So you say that, because Sun/IBM/Google/whoever has its own standard, Microsoft should have its own as well? That's BS!!! Just to start, ODF doesn't belong to Sun or IBM or anybody, it belongs to the world. Anyone that wants to implement ODF can, today, now, download, for free, a LGPL'd software that can be modified however you want, and run it. You can even run it on Linux, reducing your costs (and headaches) in software licensing to zero.

ODF is what is leveling the playing field. Before ODF, all other competitors were in an endless game of catchup with Microsoft, a convicted monopolist that was using its lock in to force customers to buy Office (if people wanted to open documents from others), to upgrade Office (if they wanted to be able to open the latest documents) and to buy their crap OS (after all, if they wanted to run MS Office, they just had to). Are you saying that MS is the victim of all of it?

Thanks to Microsoft thinking they're superior, they didn't get involved in the standardization of Office formats. Of course, they thought, all their business model is based on people not knowing what's inside, and not being able to interoperate. But, big surprise, once ODF had the ISO stamp on it, governments that were unhappy with Microsoft (Who wouldn't be? Only boobs like Rick that are on their payroll) started adopting ODF as the only document format for their use. Why wouldn't they? It's well documented, there are multiple vendors, including open software implementations.

What could poor Microsoft do then? Well, they should come up with something, so they decided that the best way to keep their status quo would be throw mud into ODF and propose their own "standard" to be used instead. Yes, instead of Microsoft implementing ODF, in which case it would enable interoperability with most other Office suites (OOo, StarOffice, Lotus Symphony, Google Docs), no, they decided to push for their own format, and then every other vendor would have to implement it, instead of them having to do the work.

And how can they make sure they will be ahead? Well, first, make an incomplete specification, one that doesn't say how to do macros, one that doesn't specify exactly how to do some little details, so that no other application will achieve 100% interoperability. Do it huge as well, thousands and thousands of pages, so that nobody will be able to review it, and nobody will be able to implement it quickly. While they win years with this, they're ready to launch a new version of Office, which introduces new "features" (and probably new "bugs") that they'll push for a second version, and keep all other vendors playing catch up again.

If you deny this, then I don't know in which world you have lived so far. Maybe the news don't get to Australia. Or maybe your pockets are too full of dirty money from them.

In all Microsoft history, they've done it and done it again. BUSINESS AS USUAL for them. Just look at Internet Explorer, look at what they did with HTML and CSS. As so said XML expert, you can't deny that what they did with those standards was really nasty.

And then you say that "ISO has to be fair" and "Microsoft should have a chance"... Well, they do have one. Their only chance now is to implement ODF. Instead of making everybody lose their time (and patience, mine is at an end!) with that bunch of crap, they should just use the resources to implement ODF. That way, they wouldn't lose their precious government contracts, only if their software is inferior to other vendors, but don't they think their products are so great? But no... this is Microsoft at its purest (which in their case means nasty). They'll rather use fear, uncertainty, doubt, corruption and bribes than having to compete on a fair leveled playing field.

So, CUT THE CRAP RICK! If your argument is that Microsoft should have their standard just because IBM/Sun have theirs, you are really desperate. Maybe it's that bonus they promised you if it's approved. Well, forget about it, because you're not getting it! People are tired of Microsoft's dirty practices, and will fight them as long as needed.

And by the way, the name of the guy is not "Arnold", it's "Arnaud". Show some respect. He actually wrote just about that in his blog today, you should read that. It's actually a more interesting reading than what you have to say.


Rick Jelliffe
2008-03-25 00:29:55
Phil: No, I am not paid by Microsoft for this blog. I don't have any financial ties to them or projects for them that I know about. Since I have already responded to this a tedious number of times, I assume that your purpose in writing it is to join Bob Sutor's McCarthyist campaign.

Arnold is the anglicized version of Arnaud. I am not aware of any derogatory meaning of that name, and certainly none was intended. I have changed it, since it matters to you.

You mention competition and catchup. Yes, I think ODF is great because it is one of the things that have forced MS to do the right thing and adopt an XML-in-ZIP format, have an open license, start on the road to convergence, and put their spec on track for standardization. And an ISO OOXML in turn will have a good competitive effect on MS' competitors: even IBM/Lotus is starting to adopt ODF. And the ISO standardization of OOXML is providing the motivation for ODF to get fixed up in turn so that it can compete: ODF 1.2 may leapfrog in front of OOXML. Which will in turn provide the competitive impetus for ODF to improve.

Monoculture does not allow this. Whether the monoculture is called ".DOC" or ".ODT" does not matter, where you only have one technology that utterly dominates there is no impetus for improvement. The binary formats for Office, and much of the crap that we have been resolving through the ISO process, are clear signs of this accumulation.

Look at the changes made to ODF and OOXML in the area of accessibity for example, directly as outcomes of the standardization process. Wonderful! One of the big problems with standards is when there is no competitor technology: companies start to compete on marketing, reputation, non-standard product features, lock-ins and so on. And very often the technology stagnates: look at how HTML has stagnated at W3C over the last decade.

I don't want to reduce MS' culpability there, but the thing that has caused the renewal in HTML for HTML 5 has been the competition in the non-standard browser format realm: in particular things like Flash and the various XUL's. The browser makers, not lead by MS, have realized that they need to evolve HTML for it to remain relevant. Now this is real competition.

What ODF does is create a market where the also-rans are not trapped in this catch-up mode, I agree with you there. But it does not mean that therefore MS is trapped into a catch-up mode. Instead, it means that both sides find themselves entered into a frog race, for the public benefit.

Competition is not just between company A and company B, or between distribution license C and distribution license G. Standards work best when they enable competition: not only is a richer set of solution better to ensure that the optimal tool is chosen for each job, but because it forces technologies to be evolved to their optimal forms (and sometimes ultimately past them, but that is another story.)

Calling for a monoculture of ODF does not help create competition, it thwarts competition by stopping this leapfrogging. Just as bad, it forces the competition to occur within the standards forums, which leads to factions and bad standards. No-one seriously can believe that if MS sits down at a table at OASIS with IBM, Oracle, Sun and other sworn competitors, a requirement that only MS (and its zillions of users) had would be heard on its merits.

My commitment to supporting plurality is not a new thing: Google for "organic plurality" and you will get my 1999 article "How to Promote Organic Plurality on the WWW" which lays out many of the issues (some of which found fruition in Schematron.) I think this kind of article shows that my position in supporting plurality is not new, predates ODF/OOXML and so on, and that therefore you owe me an apology. The ease at which you are happy to blacken my public name shows how hollow your motives in defending Arnaud's written name really are.

By the way, if you cannot even write a civil letter, and refrain from calling me an idiot and accusing me of taking dirty money I won't print any of your comments. I have warned you about it before, and removed previous of your emails. Are you arguments really so weak that you have to resort to libels and personal attacks? On other anti-OOXML forums this week I have been called names, and the lie that I did something secret for editing Wikipedia was even resurrected.* IBM's most involved standards people have publicly endorsed the idea that people with dissenting voices stake their reputations, and I have been hoping the trained monkeys would keep in their cages, but it seems my hope was in vain.


* For latecomers, there is a claim that I was caught secretly editing Wikipedia entries after being paid by Microsoft, while the truth is that it was not secret (I wrote about it on this blog beforehand) and I was not caught (I raised the issue first) and it did not involve editing (I followed the rules and merely contributed to the discussion pages on the subject.) When you see someone still raise this issue a year after, it is a good indication that they are either liar or willfully ignorant. In Colbert's terms, "truthy" rather than "facty".

Rick Jelliffe
2008-03-25 00:57:17
Glen: On your second issue of informative versus standards track RFCs (is my memory failing, or is it actually that the RFCs formally are drafts, and internet standards are the ultimate stage, but very frequently there is no motivation to progress the RFC through to to standard because people take the RFC as if it were a standard?) there are indeed different classes of ISO publications.

International Standards are the top of the tree. Then there are different classes of Technical Specifications, in particular there are technical specs for technologies that are en route to being submitted as standards in the future, but there is a market requirement for them to have some kind of number now regardless of their future development, and technical specs for documents that are not expected to become standards (e.g. obsolescent or legacy standards.) There is also a kind of numbering for publicly available specifications and something called an International Workshop Agreement, which I have never seen.

So ISO does have a good range, and ISO/IEC JTC1 has modified names and procedures for them. As I have written in this blog recently, I think obsolescent technologies should be put through as Technical Specifications (which is akin to the informative RFC) while living technologies should be International Standards, to ameliorate market domination and allow international review.

Your first comment makes a point about the status of OSP and IPR in future versions of the standard. The OSP specifically includes future versions of the standards as long as MS is still involved in them. Note that MS has participated in ISO OOXML:2008 so that is included. However, if the anti-OOXML people stacked SC34 and changed ISO OOXML:2010 is ways that was unacceptable to MS and MS pulled out, then the OSP would not cover these *additional* parts of OOXML. However, the coverage for the old parts that were in ISO OOXML:2008 would *still* be covered through that standard.

What I think should be mentioned, is that a lot of this concern about IPR is irrational. MS for example has not issued an OSP that provides patent protection for technologies that ODF might potentially use. And Sun and IBM have not issues OSPs for their patented technologies that OOXML might potentially use.

Now, given that most of the technology in publishing and using markup is way over the statutory 27 years, it really is dubious that there are non-junk patents in this area for anything fundamental. So the way for implementers of office suites who are genuinely concerned about IPR to have peace of mind is to implement both ODF and OOXML, and so have get the benefits of both side's IP protection. And for the rest of us integrators, when was the last time Microsoft or IBM or Sun sued integrators over IPR issues? We are their market not their competitors.

Rick Jelliffe
2008-03-25 01:16:44
Tsu Dho Nimh: (great name!)

I have been a technical editor too. But a standard is not a technical manual: it is not a training manual or teaching manual or blueprint for software. In general standards are aimed at expressing concisely information aimed at people who already are subject-matter experts. It is one of the drafting problems of DIS 29500 IMHO that it is excessively tutorial already; this is something that the BRM did not really agree with me, several delegates said they found the repetitive tutorial parts useful.

So if a person who is not a subject-matter expert does not find a standard crystal clear should not be a source of wonder, it is the usual case. For example, in ISO drafting, there is a rule that definitions of things should all be removed to a common definitions section: this means that important paragraphs almost always require page flicking, because information on a topic will not all be available as part of that topic. But it is just a literary convention which you get used to, and is helpful for reducing ambiguity, encouraging definite terminology, and removing duplicate specification statements.

If you think OOXML has puddles of dog's vomit, I recommend you either join in the OOXML effort at SC34/Ecma to make it better, or if your inclinations lie elsewhere, join in the ODF effort at SC34/OASIS to make it better. However, to try to claim that the whole thing is rubbish is trivially disprovable by anyone who cares to look at it: the lion's share of it is more than adequate.

And the BRM process has improved it significantly too. As a concrete example, during the BRM I had to look up the syntax for OOXML's formulae, to compare with OpenFormula. The original draft (DIS29500 mark I or ECMA 367) used a crappy home-made semi-BNF notation that simply was unusable. But DIS29500 Mark II, the post-BRM version, uses standard ISO BNF and was completely clear and directly usable.

I have always had a lot of faith in the ISO process for turning out significantly improved results, and the BRM has clearly delivered on that. The ISO maintenance process is a good forum for continuing this, both at a low level for getting bad sentences clarified and at a higher level for exploring strategies for convergence, and continued improvements in internationalization, accessibility and modularity.

(I have noticed a little trend for some people complaining about DIS 29500 to slip in problems that have actually been addressed during the BRM. Naughty. Comments about the text need to clearly state whether they apply to the forthcoming "mark II" post-BRM version or not; and if the writer is no sure what will be in the forthcoming version they should avoid making blanket statements that may no longer apply or make a suitable disclaimer, I would have thought!)

Rick Jelliffe
2008-03-25 06:29:34
Eduardo: Ah the fallacy of the excluded middle again! You might like to consider that there is a middle route between accepting all standards regardless of quality and rejecting all of them unless they are perfect.

That is to make sure that the ducks are lined up with the big-picture issues such as organization and conformance, that all the low-level issues such as typos have been fixed, that bottom line audit issues such as internationalization, accessibility and modularization have been addressed, and that all known issues as at the cut-off period for the review have been resolved. And then, that there is an effective maintenance process in place to handle further issues, incompletely resolved issues, and new developments. OOXML is easily at that stage now: I wouldn't particularly lose sleep if it had extra review but I wouldn't lose sleep if ODF were withdrawn for the same reason...however the trouble with doing the extra review in some pre-standards organization rather than through maintenance is that we all know that the purpose of the noisiest people calling for extra review is not the ultimate improvement of the standard but the stymieing of its adoption.

The best forum for review will be the maintenance process at SC34, organized as a "perpetual ballot resolution meeting" with new issues coming in regularly and disposed of promptly.

G Fernandes
2008-03-25 09:09:09
[QUOTE]The maintenance process is the best place to deal with remaining issues.[/QUOTE]

You look old enough to have been around when Microsoft pushed the so-called "standard": ECMA script - more widely known as JavaScript. It's frankly quite amazing that you're as naive as a 2-month-old baby with regards to Microsoft's tactics.

While it's a very GOOD thing to have an open mind, it's simply naive to have a mind so open as to fall for the same trick by the same offender twice.

Rick Jelliffe
2008-03-25 09:25:50
Gerard: Are you saying that no maintenance process has ever been successful at ISO? Or just that when Microsoft is involved it makes things more difficult? Or that when other large companies are involved the same issues do not arise?

This is why I have called for continued pressure and involvement: there always have to be carrots and sticks. Some of the biggest pressures will be that ODF causes pressure on OOXML and OOXML applies pressure on ODF. (However, they will also free up some pressure: ODF does not have have the legacy material that OOXML has, and OOXML does not have to have the platform-independence and elegance that ODF should have.)