Geneva, Day Five

It's finally over! I'll give it a few days before blogging about this fully, but what can I say? It certainly was something historical. I met quite a few interesting people, worked with Microsoft and other XML experts and tried my best to improve the spec as much as I could. I helped guide the Malaysian delegation, and that by itself I can safely say I am proud of my achievements.

I can vouch that everybody in the BRM did their darnest to improve the spec. Microsoft Business Partners (and there were a lot of them) took this chance to make sure that they got as much information as possible. Free and Open Source Supporters worked surprisingly well with the Microsoft techies to clarify and expand on areas. Standards Experts refined language and corrected issues which may/will/shall hinder future problems of interpretation.

Any effort was an improvement, and that by itself could mean that the BRM was a 'success'. Yes, it was a success DESPITE the what we had to work with, and DESPITE the time limits we had to work under.

The reason why I haven't been blogging since Wednesday (Day Three) was because work just caught up with me. Items which were too complex for an immediate vote had to be taken "off-line". Work had to be done in collaboration of other National Bodies who do not necessary speak your native tongue during the breaks. We had to get all the outstanding issues modified, compromised and resolved. During the meeting, we had to  zoom through the voting processes to get our efforts recorded. It was quite confusing because we had to keep an eye on updates and collaborations on our resolutions, listen out for voting items of interests, and convince fellow delegates to vote for certain items. It was quite stressful and it's no wonder people felt completely beat after the day ended at 5pm.

But the day doesn't end there. More work on the resolutions had to occur. Logistical issues like finding a room for discussion had to happen. Some active members were shuttling from room to room to resolve multiple issues. Email and IM collaborations occurred and getting the 'blessings' from Ecma had to happen.

We eventually found out that if any changes affected current implementations it would certainly be rejected. This seriously compromised any elegant solutions, and it forced us to be mindful of the "existing corpus of documents" in the wild. I personally don't believe that that should be our problem, but there was a large and vocal voting bloc which would oppose any changes to the spec which would 'break' Ecma 376.

This was why appeasing Ecma had to happen. Even though they rushed their Ecma International Standard, and Microsoft took the risk in shipping Microsoft Office 2007 last year, we now have to bear the burden of having to support its limitations. This also means that future maintenance changes would get harder and harder. One day I will blog about the process of getting a relatively simple change into the spec.

The final day was absolute mayhem. We had to submit decisions on over 500 items which we hadn't have the time to review. All the important issues which have been worked on repeatedly happened to appear on this final day. So it was non-stop important matters. Unfortunately I was caught up in a change from Malaysia, so I must have missed deliberating on a few important matters.

But it's all over now. Due to the quirks in the voting mechanisms, a reported 98.4% of Ecma resolutions were approved. This on the surface projects an impression that the BRM is a resounding success. Unfortunately this is not the sentiment of the majority of participants, as Frank Farance, the very active and positive head of delegation for the United States of America, said publicly of this matter:

"Virtually every comment we processed did not survive unedited," he said.

The 80 percent of comments that were not discussed during the meeting were put to a "default vote," resulting in the automatic adoption of ECMA's recommendations without modification by delegates, he said.

This is not in criticism of the Convener Mr Alex Brown. He had a monumental task ahead of him at the beginning of the BRM. The chips were stacked high against him. It was not the failure of the National Bodies which attended. It was merely a failure of the process. And it may not be the failure of ISO as a process for creating standards, but mainly because a client chose the wrong method in forcefeeding a large draft standard in the conservative process of the ISO.

It was a failure of the Fast Track process, and Ecma for choosing it. It should have been obvious to the administrators that submitting a 6000+ page document which failed the contradiction period, the 5 month ballot vote and poor resolution dispositions, should be pulled from the process. It should have been blatantly obvious that if you force National Bodies to contribute in the BRM and end up not deliberating on over 80% of their concerns, you will make a lot of people very unhappy.

I think coming into the BRM at the beginning of the week, some people were optimistic that this could make a positive difference. But judging from the reactions from the National Bodies who truly tried to contribute on a positive manner, without having their concerns heard let alone resolved, they leave the BRM with only one decision in their mind come March 29th.

The Fast Tracking process is NOT suitable for ISO/IEC DIS 29500. It will fail yet again.  And this time it will be final.

And please now, don't say we didn't try ...

yk.

Comments

[Inigo]

I can't say if this is generally true, but I think they were willing to change anything that had a clear and unambiguous mapping from the Ecma-376 format to a new DIS29500 format.

So dates, for example, were a problem for them: because for corporates with lots of interconnected spreadsheets, with dates stored as numbers and used in formulae, it's hard to work out whether they're supposed to be numbers or dates. So, the mapping is complex, and even if you think you've dealt with everything, there's the potential for breaking legacy docs.

A specific issue that they were willing to break compatibility for was the "storing of escaped XML in attribute values" issue (in the end, compatibility was kept, but that was through other countries arguing, not Ecma). I assume this is because there was a straightforward one-to-one mapping between the escaped XML and the unescaped XML.

[Yoon Kit]

Inigo,

> Ecma themselves weren't among those arguing for
> compatibility. They were happy to make changes
> that broke Ecma-376 documents, and presumably Office.

Can you describe which items they were willing to modify which broke Ecma376 compat?

For the 2 items which I was working on, "Dates" and "Ceiling", it was made very clear to us that we couldn't change anything which broke compatibility with Ecma 376 (MSOffice 2007).

Ecma has a rep who "represents a large corporate customer" to argue that "as a user of Microsoft's product, we can't afford to have any changes which breaks our legacy documents." He didn't provide any constructive advise on how to fix things, but just hung this requirement over our heads during the discussions.

This was made VERY clear. I may blog about this soon.

Otherwise, they would have accepted Antonios' Date solution, and my original Ceiling solution.

Instead we had to dance around Ecma's self imposed restrictions, and come up with a compromised solutions which didn't solve the problem 100%.

yk.

[Inigo]

Hi Yoon-Kit, Bob, Rob;

I think Jesper, Doug and everyone else are saying broadly the same thing here.

Some national bodies felt that it was important to keep existing Ecma-376 documents valid and compatible, and some national bodies thought it was better to remove compatibility with these documents in the interests of making the spec cleaner. I think both sides had some reasonable points.

I think it's important to say (since I've already seen this misinterpreted elsewhere) that Ecma themselves weren't among those arguing for compatibility. They were happy to make changes that broke Ecma-376 documents, and presumably Office.

Anyway, good meeting you, and I hope we can meet up again in less charged circumstances.

Inigo

[Bob Jolliffe]

I can confirm Yoon-Kit's comment regarding breaking compatibility with ECMA-376 (and I was in the room). The question of the scope of DIS29500 was raised repeatedly from the first day and eventually "resolved" on the final day.

During the intervening period it became clear that there was a growing assumption that the intent of the standard, to maintain backward compatibility, included compatibility with ECMA376 and presumably Office 2007 - not quite the same thing I know. A number of proposals which threatened to break that compatibility were rejected on this basis. Of course we didn't really discuss a significant number of resolutions so the point could be made (as Jesper and Doug have made it) that these were only a few instances.

[Rob Brown]

Hi Yoon-Kit,

Thanks for your very interesting write-up. I was very alarmed by your comment "We eventually found out that if any changes affected current implementations it would certainly be rejected".

I asked Jesper Lund Stocholm about this on his blog at http://idippedut.dk/post/2008/03/BRM-aftermath.aspx, and both he and Doug Mahugh replied to say that they disagreed with your statement (it did happen in a couple of isolated incidents, apparently).

Could you please provide some more detail or clarification on this? I know that you can't "name names", but I'm struggling to reconcile your statement with those of Jesper and Doug.

Thanks again.

[orcmid]

Thanks, Yoon-Kit. I think your appraisal is very clear and I appreciate the way you have expressed it.

It will be very interesting to see what JTC1 says about this and how it wraps up at the end of March.

[Yoon-Kit Yong]

Terry,
If you notice, the link to Andy's site was from the 98.4% figure which I quote. I can attest that this figure was featured prominently at the end of the BRM to prove its "success".

So it's only the statistics which I needed from Andy's site. It does not mean that I agree nor disagree with whatever Andy has commented. If I quoted a block of text, then you should have full right to make your comment, but I did not.

On my comment on Alex Brown, I believe that he is a good man who has been unfortunately placed in a poor situation. He made the best of it, but the process failed him. IT IS NOT HIS FAULT. The Fast Track process was not suitable for this beast of a draft standard.

I hope that is clear.

Regards,

yk.

[Terry]

I see you say you aren't intending to criticize BRM convenor Alex Brown, but you also link to Andy Updegrove's site (someone incidentally who was not present in the BRM). Are you aware that Alex Brown is disputing Andy's recitation of what went on in the room last week.
http://www.consortiuminfo.org/standardsblog/comment.php?mode=view&cid=18785

[carlos]

Carlos, did Malaysia vote "approve" or "dissaprove" to the 80% of comments don't discussed?