Archives for January 2008

The Case for Harmonization

2008/01/31 By Rob 25 Comments

Depending on who you ask, document standard harmonization is either impossible or inevitable, anathema or nirvana. Let’s dig a little into this question and see if the two sides are really that far apart.

First note that many JTC1 NB’s raised the issue of harmonization in their DIS 29500 ballot comments last September. Some merely requested harmonization, such as Korea, South Africa, Belgium, Peru, Switzerland, or the Czech Republic, while others in addition outlined ways to achieve harmonization. For example, AFNOR, the French NB stated:

After 5 months of extensive discussions between stakeholders in the field of revisable document formats, AFNOR, in the aim to obtain a single standard for XML office document formats within 3 years, makes the following proposal:

Split the current ECMA 376 standard in 2 parts in order to differentiate the essential OOXML core functions necessary for easy implementation from those functionalities that are needed for the exchange of legacy office file formats;

Incorporate the technical comments below and those in the attached comment table submitted to the Fast Track;

Attribute the status of Technical Specification to both parts;

Establish a process of convergence between ODF (already standardized as ISO/IEC 26300) and the above mentioned OOXML core. ISO/IEC shall invite parties involved to commit themselves to initiate simultaneously the revisions of the existing ODF v1.0 and the OOXML core in order to obtain at the end of the revision process a standard as universal as possible.

(Note that a Technical Specification, in ISO process, is for proposals which lack insufficient support for approval as an International Standard, but for which publication is still desired. This may be appropriate for OOXML.)

New Zealand’s proposal was similar:

OOXML should be considered by JTC 1 for publication as a Type 2 Technical Report.
Seek to harmonize with the existing ODF standard to reduce the cost of interoperability, cost of having two standards, and cost of support/maintenance .

Further, the NB’s of Great Britain, New Zealand, and the United States requested that specific features be added to OOXML in order to improve interoperability with ISO ODF, in total 40 features such as the ability:

to have more than 63 columns in a table
to have background images in tables
to have font weights beyond “normal” and “bold”.

Notably, these were the same features that Microsoft sponsored translator project on SourceForge identified as needed to improve translation with ODF. These are the features that the project noted were lacking in OOXML.

Ecma rejected every single one of these requests. They did not argue that the requested features were unreasonable. They did not argue that the requested feature was not needed. Their argument was that harmonization of the formats was not necessary because there exist tools that will translate between OOXML and ODF. In other words, they rejected these requests merely because they were pro-harmonization, regardless of the underlying merit or need of the feature. Ironically, Microsoft’s conversion tools are restricted in their fidelity because of the lack of these very features.

On the question of harmonization, we are either moving toward it, or we are moving away. There is no time better than the present to harmonize. Waiting will only make matters worse, as we will then need to consider legacy OOXML documents as well as legacy binary and legacy ODF documents. The Ecma response does not move us toward harmonization, but starts down the road toward further divergence, a long and costly divergence.

Tim Bray made the critical observation back in 2005, “The world does not need two ways to say ‘This paragraph is in 12-point Arial with 1.2em leading and ragged-right justification’.”

Microsoft likes to claim that harmonization is impossible, that slapping together the features of both standards would lead to a messy, impenetrable mess. Of course, but only an idiot would suggest that as an approach to harmonization. So why do they always bring that up as their strawman?

A look at OpenOffice and Microsoft Office shows a huge degree of functional overlap. Harmonization starts from looking at this functional overlap – and there is a significant, perhaps 90%+ area where they do overlap – and expresses the functional overlap identically, using the same xml schema. In other words, harmonization identifies the commonalities at the functional level and finds a common representation for that commonality.

It would also be expected that the common functionality between ODF and OOXML would also include a common extensibility mechanism, a way for a vendor to express application-specific features that are outside of the harmonized standard.

The remaining 10% of the functionality would be the focus of the harmonization work, the area that requires the most attention. Some portion of that 10% will represent general-purpose features that we can imagine multiple application supporting. We take those features and add them to ODF. That remaining portion of the 10%, which only serves one vendor’s needs, such as flags for deprecated legacy formatting options, could be represented using the common extensibility mechanism.

Does this sound impossible? That’s not what Microsoft says. Gray Knowlton, Group Product Manager for Microsoft Office, was candid to PC World a couple of weeks ago:

Also, if individual governments mandate the use of ODF instead of Open XML, Microsoft would adapt, Knowlton said. The company would then implement the missing functionality that ODF doesn’t support. However, those extensions would be custom-designed and outside of the standard, which is counter to the idea of an open document standard, Knowlton said.

So we’ve agreed that this approach is technically feasible. We’re also agreed that extending ODF outside of the standards process is not a good idea. So the obvious solution is to extend ODF within the standards process. So, let’s do it! What are we waiting for?

There is no reason why, by a harmonization process, all of the functionality of Microsoft Office cannot be represented on a base of ISO 26300 OpenDocument Format. I personally, as Co-Chair of the OASIS ODF TC, stand ready and willing to sponsor such a harmonization effort in OASIS. So let’s start harmonization now, and avoid further divergence.

My read of NB comments indicates that there is a sizable bloc, perhaps even a decisive bloc, of NB’s who are in favor of harmonization. Lets push on this and articulate a roadmap along the lines of the proposals by France and New Zealand, that accomplishes this.

What every engineer knows

2008/01/25 By Rob 25 Comments

Let’s work through a few hypothetical “what if” scenarios to illustrate some common engineering themes related to quality control and the inherent stresses between those who build, those who test, and those who sell. Every engineer is deeply familiar with these patterns, but I believe even the general reader will understand the dynamics better by reading these scenarios.

Let us start by imagining that a new bridge is being built in your area. The company that is building the bridge is very eager to have it open by a particular date. In fact, their contract calls for monetary penalties for every day the opening is delayed beyond that date. However, before it can be opened to traffic, it must be inspected to ensure that the welds conform to the applicable standard. For sake of argument let’s say the standard is the AASHTO/AWS D1.5M/D1.5:2002 Bridge Welding Code.

The inspectors may inspect all of the welds and find that they are all acceptable. What do you you think of this, as someone who will soon ride over that bridge? Is this good news? Yes, if you trust the expertise and independence of the inspectors, and their testing process and equipment. If the inspectors do their job properly, and they find no defects, then this indeed is cause for celebration.

But what if the inspectors found a handful of defects, perhaps some welds that failed fatigue testing? If indeed the defects are few, and are localized, then they can be fixed and retested and we can still open the bridge on time. But it is critical that the changes are localized, that there are no far reaching changes. A bridge is not just a collection of independent pieces of metal. They all work together, and as a whole have static and dynamic mechanical properties and relate to load capacity, stresses, thermal characteristics, resonance, etc. Although some fixes may be only localized in their impact, meaning only the area changed needs to be retested, other fixes may have a larger impact and require that everything be retested.

In any complex system, some defects are expected. A sign of good of engineering process is that larger, structural defects are detected or prevented at the earliest possible moment, when they are easiest and least expensive to fix. Where this is not accomplished, large design defects may be first detected at final inspection time, and costly and pervasive rework and retesting may be required, or in the extreme, the bridge may need to be torn down.

The engineering maxim is “fail early”. Now this may seem like an odd thing to say. Shouldn’t we always try to prevent failure or at least delay it as long as possible? Certainly, if you can prevent failure, then do so. But it is rarely the case where all defects can be prevented. But as engineers, we can design systems, and testing procedures so that flaws become evident as early in the process as possible, when they can be fixed in architecture and design documents rather than in built structures, or at least be found as early in the construction process as possible. This is a frequent source of stress between those who build and those who sell. The important thing for all to understand is that failing early is actually a form of risk reduction. The sooner you fail, the sooner you can fix the defect and start again.

Back to the analogy.

Let’s build another bridge. Along comes MegaCorp, who wants to build a bigger bridge, a much bigger bridge than any attempted previously, a MegaBridge. There is nothing wrong with that per se. The history of engineering is the history of making bigger pyramids, wider vaulted ceilings, taller skyscrapers and longer bridges.

Of course, the fact that MegaBridge is right down the street from the new bridge that just opened last week is a bit odd. But MegaCorp tells us that is OK. We’re not required to use their bridge if we don’t want to.

Further suppose MegaCorp also wants to construct this MegaBridge in record time, faster than others have constructed bridges even a fraction of their size. This is certainly ambitious, but there is no law against ambition. Progress is made by those who are ambitious. We learn from their successes as well as their failures. The important thing is that an ambitious MegaBridge, like any other bridge, is held to the same standards as any other bridge, that proper inspections are carried out and that quality criteria are satisfied.

Months later and the construction of MegaBridge is complete. Time for inspection. But one problem — the MegaBridge is so large that it is impossible to carry out an inspection in the scheduled time. There are simply not enough inspectors available to carry out the task and complete it by the targeted opening time.

What should we do?

It is useful at this time to consider another engineering maxim, “fail safe“. If a system is overloaded, or detects an error condition, it should fail to a safe state, a state least likely to cause damage. We see this applied in many of the systems we use every day. Traffic lights fail safe to flashing red, GFCI circuits fail safe by switching off current if a ground fault is detected, and train air brakes fail safe by applying the breaks if air pressure is lost.

The concept of a “fail safe” applies to processes as well as mechanical systems. A committee, by having a quorum requirement, ensures that it fails to a harmless, inactive state if a snowstorm prevents a representative portion of the committee from attending a meeting. A criminal trial, by presuming innocence and requiring a unanimous verdict to convict, ensures that in case of deadlock, the defendant is let free. Similarly, a bridge quality inspection protocol should include a fail safe provision, that if the inspection cannot be completed, the bridge should not be certified as fit for use. The inspection process should fail safe to non-certification. Ordinarily, engineering practice would be to take whatever time is necessary to inspect the bridge fully, or fail the inspection.

(Here our tale diverges from standard engineering practice and starts to relay, by analogy, the increasingly bizarre tale of OOXML’s exploits in and of ISO.)

But MegaCorp wants the MegaBridge to open on time. They force the inspection to continue, even though the inspectors claim there is not enough time. In order to “help” the inspection and despite the obvious conflict of interest, MegaCorp instructs a large number of its own employees, qualified or unqualified, to volunteer as bridge inspectors. They further recruit employees from subsidiaries and suppliers to become inspectors as well. In at least one case, MegaCorp tells a supplier, newly-minted as an inspector, “Don’t worry if you know nothing about bridges. We’ll tell you what to say. All you need to do is say that the bridge is safe. You’ll be rewarded later for helping us here.”

So the bridge inspectors go out, old and new, qualified and unqualified and come back with their individual preliminary reports. The older, more experienced inspectors are critical in their evaluation:

The bridge is full of defects. Although, as we mentioned earlier, the mandated schedule did not permit us to test all of the critical welds, of the ones we did test, we found numerous defects. In fact, the number of defects we report is artificially low, since it was limited by our available inspection time. If we had been able to complete a full inspection, we would have detected and reported many more problems.

We further found pervasive structural problems. This bridge is unsound. We can not certify it. We further question why it is necessary to open up a new toll bridge at all, when we just opened up a new free bridge down the street.

The newly-minted inspectors, who for the most part are economically dependent on MegaCorp, were more supportive:

Although some minor problems were indicated, we believe these can all be fixed during routine maintenance. We are not concerned about the time permitted for inspection. We did what the process required. And when you count all the new inspectors that MegaCorp has brought to the process, no bridge has been more inspected. Considering the number of defects reported, this is the most-inspected bridge in history. We recommend that MegaBridge be certified and opened as scheduled.

Of course, from an quality control perspective, this is seriously flawed. The checks and balances between those who build, those who test and those who sell have been eliminated. Although it would not be unusual for some MegaCorp inspectors to be involved in the inspection process, the late arrival of so many unqualified, newly-minted inspectors, and the shift of balance to MegaCorp’s hand-picked inspectors, calls into question the independence and technical sufficiency of the entire inspection process.

The inspectors are polled to see whether the bridge can be certified. The vote is close, but the answer is no, the MegaBridge cannot be certified in its current condition. The inspectors, mainly the older, more experienced ones, record a report of 3,522 specific defects in the MegaBridge, far more defects than have ever been found in any other bridge.

MegaCorp is irate. They blast the experienced inspectors in the press, while simultaneously reassuring their stockholders that this setback is just the next step forward to success. They give their engineers the inspection report and demand a quick response. “We must open the bridge on time!” they yell. The MegaCorp engineers work day and night, over weekends, over the holidays even, in order to develop written proposals to address each of the reported flaws in the bridge.

The inspectors are given the proposals and asked whether they believe the proposals are sufficient to allow the MegaBridge to be certified. Although the newly-minted inspectors are quick to affirm the adequacy of the proposal, the old-timers just shake their heads in disbelief, with one stating to the press:

You could fix every last defect in that report and the MegaBridge would still not be sound. Since we never inspected all of the critical welds in the first place, fixing only the defects we reported is insufficient. It is not enough for us to merely retest the ones we reported as defective. We need to test all of them.

Also, the fact that you are making pervasive changes to the road surface, the suspension materials and the pillar diameters, far-reaching design changes which were clearly rushed and have not gone through normal review procedures, I’m afraid that all of our previous tests are now invalidated as well.

Additionally, many of your proposals either avoid addressing the flaws, paper around the flaws, or even introduce new flaws. We need to re-certify the new design before we can even think about retesting the bridge.

However considering the huge number of defects reported, the even larger number of defects undetected because of lack of inspection time, the questionable competency of the newly-minted inspectors, and overt corruption of the process by MegaCorp, my recommendation would be to tear this thing down before it falls over and hurts someone.

Thus ends the tale of what every engineer knows.

Comedy tonight!

2008/01/25 By Rob 1 Comment

Some people think I’m funny. Maybe it is because I like to listen to sea shanties as I blog. Maybe we just live in funny times. In any case, I’d like to highlight three things that have made me laugh this week. And trust me, I have exquisite taste.

First up is Tiffany Maleshefski in her eWeek Desktop Confidential column, and her critique of the Burton Group Report, written in the form of a love letter to Microsoft.

Next is Ecma’s Magic 8 Ball, the source of responses to your NB’s ballot comments, contributed by a reader who wishes to remain anonymous.

Finally, on YouTube, a droll faux-endorsement of OOXML by FFII President Pieter Hintjens called “Six Reasons to Migrate to OOXML“.

The Standards Trolls

2008/01/21 By Rob 15 Comments

It is hard to resolve the pecking order of posters in the Microsoft blogger echo chamber. So let’s just remark that all the usual suspects assisted in this one: Doug Mahugh, Stephen McGibbon, Oliver Bell, Gray Knowlton, etc. Mix together, shake, repeat, turn the crank and presto! Out comes news.

Mary Jo Foley at least poses it as a question:

What’s your take? Are IBM and Google talking out of both sides of their mouths, when it comes to their “OOXML is evil” claims? Or is Microsoft increasingly grasping at straws, as the late February ISO vote on OOXML standardization inches closer?

Eric Lai, not to be outdone, comes up with the sensational headline “Lotusphere: Whoops! IBM products support Microsoft’s Open XML doc format”, a headline made all the more remarkable by the fact that the article has absolutely nothing whatsoever to do with Lotusphere.

Well, let’s look at the “evidence” Microsoft points to and try to make some sense of it.

First up we have the Lotus Symphony support forums, where in response to a question from a user about Office 2007 support, “supportadmin3” replied “Great idea Robert!!! I will submit your feature request to the proper team…Thanks!”

I don’t know what to say about that. It is a sign of fanciful desperation to turn the courtesy of “supportadmin3” into a statement of IBM support for OOXML. It is bizarre that anyone would portray this as more than courtesy.

What else do you have?

The thundering herd also pointed out this article from developerWorks last August on how to use ODF and OOXML with DB2 9 pureXML. Does pureXML support OOXML? It sure does!!! In fact it supports any well-formed XML document or fragment, OOXML, ODF, BerniesOldTimeMedicineShowAndJamboreeML, whatever you have. DB2 pureXML can handle it all, and let you query it via SQL or XQuery. Yes, OOXML and every other XML format known to man is supported!!!

[24 January It has come to my attention that the above paragraph has caused confusion among readers who are not familiar with the term “well-formed“. This is a technical term, defined by the XML standard. It essentially means that the XML will parse, that it follows the underlying syntax of XML. It is the minimum qualification for something to be called “XML”. It does not imply any fitness for a particular purpose, or any level of quality. It certainly does not mean the XML is “easy to process by standard XML tools”.

By analogy, I could say that a novel is poorly written, boring, in bad taste and artistically without merit, but at least the author spell-checked.]

What else do you have?

Ah, yes, there is the claim that DB2 Content Manager supports OOXML. Sorry guys, that page is just noting how to add MIME types for OOXML to Content Manager. Wow, you’re moving now. With apologies to Steve Martin in The Jerk:

application/vnd.openxmlformats-officedocument.wordprocessingml.document! I’m somebody now! Millions of people look at this registry every day! This is the kind of spontaneous publicity, you’re name in print, that makes people. I’m in print! Things are going to start happening to me now.

What else do you have?

Oh yes, Document Conversion Services, in WebSphere Portal. The claim is that DCS supports OOXML. Yes, indeed it does!!! DCS, via 3rd party code, supports 100’s of file formats. So OOXML joins the elite company of supported formats, along with XYWrite (1985), VolksWriter (1982) and Lotus Manuscript (1986).

I’m elated that Microsoft thought this DCS support was worth 6 blog posts. In fact in the 5 years since I designed and wrote the DCS framework (yes, ironically, I was the architect of that component) it has never gained such notice.

But here is something you might not know about DCS. Its main purpose is to handle the graveyard formats, the formats that you might rarely find in a document repositories,but don’t want to bother installing editors for on your clients. So instead of locating and installing dozens of legacy word processors, you simply have DCS run on the server and convert, on-demand, these legacy documents into a quick & dirty HTML rendering for viewing. So, DCS is great for handling those rare times when you run across an OOXML file.

So welcome, OOXML, to the exclusive company of “Every Document Format Known to Man” . I’m glad that you are so excited. But your desperation in trying to dredge up examples of support for OOXML, any examples, is so pitiful that I feel must offer some assistance.

Let’s start with the conformance clause for OOXML (Part 1, Section 2.5), the standards language that defines what an OOXML supporting application must be able to do, in order to claim it supports OOXML:

2.5 Application Conformance

Application conformance is purely syntactic; it also involves only Items 1 and 2 in §2.3 above.

A conforming consumer shall not reject any conforming documents of the document type (§4) expected by that application.

A conforming producer shall be able to produce conforming documents.

Or, in plain English, in order to be able to claim conformance with OOXML, an application must not crash when presented with a valid OOXML document, or must be able of producing at least a single valid OOXML document. This is not exactly a high threshold.

Some examples of applications that support OOXML by that definition:

The DOS “copy” command is a conforming OOXML consumer and producer, since it can accept and produce valid OOXML documents.
The DOS “del” command is a valid OOXML consumer, and one which I heartily recommend.
WinZip, PkWare and every other Zip application out there are also conforming producers and consumers of OOXML.
Every text editor and every XML editor and every other application that can consume text or XML also supports OOXML.
Every web server and every application server, and every file system in the world can support OOXML if it can store an OOXML document without crashing or restore a valid OOXML document.
A USB memory stick is also a conformant OOXML application, since it can consume and restore OOXML documents,
An MP3 player is a conforming OOXML application, if it has a disk mode that allows files to be stored and restored.

Feel free to suggest your own nonsense.

By analogy to patent trolls, what we’re seeing here is the behavior of a standards troll — defining a conformance clause so vague that everything in the world is considered to support it, and then searching through competitor’s web sites in hopes of finding some place where they stumbled into supporting it, and then trying to extract some advantage from it.

The point should be to look for examples of where OOXML is supported to the highest degree, to point out the best examples of high-fidelity interchange that your standard allowed. You would think that with so many people at Microsoft with “interoperability” in their job titles, that this would be obvious. I guess not. But don’t be sad. You can always count on “supportadmin3” to cheer you up!!!

Within the next 24-hours, Microsoft will submit to JTC1 a set of proposals for addressing the 3,522 comments that accompanied OOXML’s failed ballot last September. We’ll no doubt hear a lot of yip-yip-yahooing on their end. Expect a major media campaign. I don’t want to take away the surprise, but I’m hearing that journalists are being flown into Redmond next week from around the world for briefings on OOXML. So, for their benefit, and yours, let’s review where we are in the JTC1 process.

What has happened so far?

OASIS OpenDocument Format (ODF) is the current ISO standard (IS 26300:2006) for XML-based word processing, spreadsheet and presentation documents. By using an open standard format like ODF, consumers avoid vendor lock-in and are able to have a choice of suppliers. ODF is widely supported by vendors, in both commercially-available and open-source software, and is seeing strong adoption world wide.

In early 2007 the European Computer Manufacturer’s Association (Ecma), after a superficial review clothed in secrecy, submitted the Microsoft-authored document format specification, Office Open XML (OOXML), to ISO/IEC JTC1 for approval as an International Standard. This provocative submission occurred only three months after JTC1 published OpenDocument Format (ODF) as a unanimously approved International Standard.

OOXML has been widely criticized as flawed standard, having been designed with only a single vendor’s objectives in mind and designed to work fully only with that vendor’s products. Also, in its rush to catch up with ODF, OOXML was submitted to JTC1 in an immature state, hastily written and insufficiently reviewed. At the time it was approved by Ecma, there were zero commercially available implementations of OOXML. The only support was in the beta version of Office 2007.

In a preliminary 30-day “contradiction period”, JTC1 member bodies were invited to raise objections if they believed that the OOXML submission contradicted existing ISO or IEC standards. Twenty countries responded in this period, most of them raising concerns over OOXML. Several NB’s raised objections to the extreme length of the proposal (over 6,000 pages) and raised IP concerns. JTC1 administrators effectively ignored all of these objections and proceeded to a 5-month ballot.

On September 2nd, 2007, after a 5-month review period by ISO/IEC JTC1 national bodies (NB’s), the ballot to approve DIS 29500 Office Open XML (OOXML) failed, not reaching the required 2/3 approval by JTC1 P-members. This ballot was tainted by many documented irregularities. Over 3,500 comments were submitted by NB’s with this ballot, documenting specific errors, ambiguities and omissions in the OOXML proposal.

What is next for OOXML?

JTC1 procedures allow a proposer of a failed standard the opportunity to respond to the ballot comments submitted, in hopes of persuading members to change their vote from disapproval to approval.

This procedure occurs in several steps. In the first step, the formal proposer of the standard, Ecma in this case, writes a Proposed Disposition of Comments report, in which they recommend their proposed resolutions for each comment from the September 2nd ballot. This is the document that is due on January 14th.

We’ve seen draft versions of these proposals resolutions, but they were provided in a rough form, impossible to review, as 3,000+ separate PDF files, amounting to over 5,000 pages, ordered alphabetically by the country that made the underlying technical comment. This is not exactly a convenient arrangement for seeing, for example, all comments related to spreadsheet date serial numbers, or for doing any other topical review. So it will be good to finally have Ecma’s full Proposed Disposition of Comments report, which presumably will be in a more usable format.

Note that the Ecma submission on January 14th will be non-binding, merely a set of proposals. Ecma does not have the power to change a single line in OOXML, since the proposed standard is under JTC1 control. Ecma can propose solutions to comments, as can JTC1 members themselves, as they did in in great numbers in the proposals that accompanied ballot comments on September 2nd. No changes are actually made until approved by the Ballot Resolution Meeting (BRM). This fact should be kept in mind as Ecma reviews with some NB’s a draft of their Proposed Disposition of Comments Report. This is just a proposal at this stage.

What about the BRM?

The BRM, or Ballot Resolution Meeting, will occur February 25th-29th in Geneva. All NB’s who voted on the September 2nd ballot are able to attend, and approximately 35 NB’s are planning on sending delegates, with attendance expected to fill the hall to capacity, 120 people. Ecma can attend, but they cannot vote.

The BRM, preferably by consensus, though formal votes are also possible, will agree on a set of changes to the text of OOXML. Proposals for changes may come from Ecma’s Proposed Disposition of Comments report, as well as from NB ballot comments. Resolutions may be debated, amended, substituted, approved, rejected, etc., according to a vote of the meeting. Or at least that’s my understanding. The actual documented BRM process in JTC1 Directives is entirely inadequate, with a lack of detail that is better suited to the by-laws of a Ladies Over-60 Bowling League than it is to ISO. The Convenor of the BRM, Alex Brown has the unenviable task of consulting bird entrails or performing whatever other divinations are required to turn JTC1’s vague scratchings into a working meeting. We wish him luck !

At the adjournment of the BRM we will have be an agreed-upon set of editing instructions for the Ecma Project Editor to apply to OOXML. Only changes approved by the BRM may be made to the standard. Note that the BRM does not indicate approval or disapproval of the OOXML standard itself. Its purpose, its technical role, is merely to make changes to the text of the standard.

What occurs after the BRM?

After the BRM adjourns (February 29th) there will be a 30-day “reconsideration” period in which those NB’s who voted on the September 2nd ballot will be able to change their vote. They can change their vote in any direction, from approval to disapproval, approval to abstention, abstention to approval, abstention to disapproval, disapproval to approval, or disapproval to abstention.

Note that the criteria for the vote is the same as on September 2nd – Should DIS 29500 Office Open XML be approved as an International Standard? It is not a vote on the BRM, nor is it a vote on Ecma’s Proposed Disposition of Comments. The question on February 29th is the same question as Sept 2nd — Is the DIS 29500 proposal acceptable?