Life in the Fast Lane

The latest in the ISO C++/CLI story

I'm going to come back to this after explaining the process of standardisation, but the recent fast-track ballot by ISO's SC22 committee on whether to adopt ECMA's C++/CLI proposal as a "Draft International Standard" decided "against". ECMA as the Fast Track submitter has been instructed to "decide whether they wish to schedule a disposition of comments meeting and to address all comments and update the text for a second DIS ballot".

I'm not sure what the other options are, but there is no reason to think that ECMA will do anything but press ahead with this standard - which, after all, is what their business is about.

ISO's "Fast Track"

ISO has traditionally developed standards internally based on principles of "consensus", "industry-wide" and "voluntary". Quoting from their website [ ISO ]:

How are ISO standards developed?

ISO standards are developed according to the following principles:

Consensus

The views of all interests are taken into account: manufacturers, vendors and users, consumer groups, testing laboratories, governments, engineering professions and research organizations.

Industry-wide

Global solutions to satisfy industries and customers worldwide.

Voluntary

International standardization is market-driven and therefore based on voluntary involvement of all interests in the market-place.

The same page gives the following overview of the process of developing a standard:

The need for a standard is usually expressed by an industry sector, which communicates this need to a national member body. The latter proposes the new work item to ISO as a whole. Once the need for an International Standard has been recognized and formally agreed, the first phase involves definition of the technical scope of the future standard. This phase is usually carried out in working groups which comprise technical experts from countries interested in the subject matter.

Once agreement has been reached on which technical aspects are to be covered in the standard, a second phase is entered during which countries negotiate the detailed specifications within the standard. This is the consensus-building phase.

The final phase comprises the formal approval of the resulting draft International Standard (the acceptance criteria stipulate approval by two-thirds of the ISO members that have participated actively in the standards development process, and approval by 75 % of all members that vote), following which the agreed text is published as an ISO International Standard.

This is inherently a slow process - and, in practice, it can be really slow (in the case of C++ it took about nine years). And many feel that standards need to be produced on a more ambitious timetable. And so, ISO created an alternative "fast-track" process that allowed it to adopt standards created outside the above process - for example "publicly available standards".

While I can't find details of this fast-track process on the ISO website (having asked around, it is part of the "ISO/IEC JTC 1 Directives" - JTC is "Joint Technical Committee"). While I can't claim expert knowledge of these I understand that the fast-track proceeds as follows: firstly, document (for example a "publicly available standard") is submitted for "Fast-Track" approval to the corresponding ISO committee. In the case of the C++/CLI proposal this is SC22 (programming languages). This committee, or rather the national bodies that comprise it, then has a thirty day period to identify contradictions that would prevent the standard being considered. (We'll revisit this idea of "contradictions" in the context of the C++/CLI submission below.) Assuming the standard survives scrutiny, the next stage is for the committee to vote on its adoption as a "draft international standard". (This is in contrast with the process outlined above where a working group formed from the national bodies on the committee work together to create a consensus before the corresponding vote.)

The progress of C++/CLI (described below) suggests that the criteria for accepting a standard for fast-tracking are not clear and that there is a failure to gain consensus from people knowledgeable about the subject area and potential impact of this standard. There is a marked contrast with standards developed by ISO itself - for these there is, for example, a requirement that a working group comprising at least five national bodies is willing to take responsibility for the work involved.

Every organisation develops a culture over the course of time that reflects the way it tries to work. And ISO is no exception to this. Most of its standards are of interest to a minority of those on the decision making panels (not surprising really, there are a lot of standards and very limited resources to pursue them). A consequence of this is that national bodies with no interest in a particular standard try to keep out of the way by automatically voting "approve" to anything that comes up for a vote. For traditional standards this is justified on both the tit-for-tat principle that others will do the same for standards that do interest them and on the assumption that those national bodies forming the working group have been diligent.

In organisational terms the fast-track is a new thing and the existing culture of "approve" by default is still operating. However, for a PAS submission there may be no national bodies interested in the standard - with the consequence that neither the tit-for-tat principle nor the presumption of diligence need apply. The effect of this can be quite alarming.

What does this mean for C++/CLI?

When it came to ECMA C++/CLI standardisation effort there was very little existing interest in SC22. Even within SC22/WG21 (C++) it was very much a minority interest - although some members of the BSI panel (and other participants in WG21) had made an effort to engage in the ECMA process. The general attitude, however, of those working on ISO C++ was that C++/CLI would be a diversion of their effort from more important issues.

When C++/CLI was submitted for "Fast-Track" the BSI C++ panel believed that there were a number of contradictions inherent in the C++/CLI submission (these are discussed in the editorial mentioned above). These were duly raised with SC22 which then chose to proceed with this submission. It isn't clear whether the objections raised by BSI, DIN (the German standards body) were considered inconsequential or irrelevant "technical comments". It does appear that the latter may be the case as, at this time, a document was posted to the BSI website requesting that national bodies "review and contributions on the relevant parts of JTC 1 Directives clause 13 on the 30 day call for contradictions during Fast Track" which suggests that it is recognised that there is ambiguity in this area.

It wasn't just the British and Germans that has issues to raise: the French C++ group also attempted to raise objections through their standards body (AFNOR) but I don't think these were actually seen by SC22 as there was some confusion regarding the language in which the objections were stated. My understanding is that the C++ group raised and/or translated their objections into French, thinking this was a requirement only to find that AFNOR would not submit them to SC22 unless they were in English.

Attitudes within WG21 changed somewhat during the Berlin WG21 meeting when, at an off-schedule get-together (sponsored - after the fact - by ACCU), Lois Goldthwaite presented the concerns of the BSI panel to many of the people active in WG21. One of the key points made in this presentation was that while C++/CLI was a natural evolution of C++ (to the CLI) it could, if ratified by ISO, be mistaken for the natural evolution of C++ that they had all been so busy working on. For ISO to ratify two incompatible "C++" standards in rapid succession would be guaranteed to create confusion.

As a result of these arguments the various national bodies active in WG21 chose to look at C++/CLI more closely and decided that they needed to act. This decision was not made lightly as there is an expectation within ISO that "no" votes are accompanied with "comments" (an informed explanation of the reasons for voting no and a suggested resolution that would change the vote to a "yes"). These comments are hard work - which discourages "no" votes on trivial grounds.

The consequence was that when it came to voting there were eleven votes in favour of accepting the C++/CLI standard and nine votes against. According to Francis Glassborow (who is better placed than I am to know who is active in WG21) all of the active members of WG21 voted against ¹ : "No one who knew anything about the subject was in favour". While a majority of national bodies did approve the standard this represents a failure to gain approval (according to the voting rules there needs to be at least 66% approval and at most 25% against - abstentions not counting).

If you look at the numbers, they prove how hard it is to defeat one of these ballots. There were eleven in favour when twelve were needed to pass. And there were nine against when six would not have been enough. Consider what would happen with a working group that, like many, has fewer active members than WG21. Or one that was less alert to events.

The role of ECMA

There are many bodies in the world that take it upon themselves to issue standards and ECMA (formerly the "European Computer Manufacturers Association") is one of many. As its former name suggests it represents the interests of manufactures (although, in line with current trends in globalisation, it in no way restricts its activities to Europe).

ECMA seems rather proud of the fact that it is behind the majority of standards fast-tracked through ISO since that process became available: "All together 250 standards have been fast-tracked since 1987:Over 80% of these come from Ecma" [ ECMA ]. Thus success progressing standards through the ISO fast track process is thought to encourage manufactures to invest in developing standards through ECMA.

The role of ECMA is different to that of ISO - the manufacturers that it represents are only one of the constituencies represented in ISO. The fact that, for example, Microsoft can gain consensus with other manufacturers for standardising C++/CLI is not a guarantee of more widespread support.

What does this mean?

There would appear to be something missing in the ISO fast-track process. While it does meet its initial goal of permitting standardisation on a much shorter time-scale it currently fails to meet the principle of consensus cited above.

There is a serious danger of the ISO stamp of approval being applied without due caution. One may hope that the review being undertaken by JTC1 will result in the process being updated to ensure that, for example, there is a quorum of national bodies interested in adopting any standard being considered.

Pending such a development there is a need for vigilance on the part of national bodies and, to assist them in this, on the part of individuals that may be aware of developments that their national bodies are not actively tracking.

Watch this space

There is another standard that bears watching to illuminate this process. Earlier this year ISO standardised Open Document Format (a format covering various office documents) through the Publicly Available Standard process when it was submitted by Oasis. Now ECMA is standardising Office Open - a corresponding format based on the new format that Microsoft's office suite will use. In due course this too will be submitted for fast tracking by ISO.

It seems absurd for ISO to standardise two competing standards in this space. This absurdity has a cost - the national bodies then have to publish these standards.

A note of thanks

I'd like to thank all those who responded to my appeal for help putting this issue of Overload together. In particular, I'd like to mention Alistair McDonald and Anthony Williams who both helped with the process of preparing material submitted by others for publication.

References

[ ISO] http://www.iso.org/iso/en/stdsdevelopment/whowhenhow/how.html

[ ECMA] http://www.ecma-international.org/activities/General/presentingecma.pdf

1. There is a partial exception in the case of Switzerland - which national body voted "yes" without first consulting its C++ experts.