Standards Best Practices Blog

A standard is an agreement among a group regarding how something should be done. Generally the purpose of the standard is so that everyone is doing things the same way, with the goal of promoting interoperability. An implementation of the standard, perhaps a device of some sort, must conform to the standard if it is to interoperate with other implementations. For example, a fax machine cannot talk with another fax machine unless they are using the same language, and an electrical plug cannot be inserted into a wall socket unless they are using the same specification for the size and shape of the interface elements.

How do we know whether a product correctly and completely implements the standard? With regards to the examples above, the most obvious way is to see if the plug fits into the socket, or if one fax machine will talk to another. This is what’s called Interoperability Testing, i.e. testing whether the implementation will interoperate with other implementations that are using the same standard.

Another method of verifying that a product correctly and completely implements the standards is Conformance Testing, where the product is tested against a list of items to see whether it performs as the standard specifies. Again using the examples above, does the fax machine send a certain signal to establish contact, and does it respond with another certain signal to acknowledge a transmission? Does the electrical plug have the proper size, shape, and spacing of male elements?

There are pros and cons of each of these types of testing. Interoperability testing is usually quite simple but wouldn’t necessarily test the product against the entire standard. It may only test the most commonly used but simplest parts of the standard. For example, it doesn’t take much effort to plug two fax machines into a phone line and transmit a document, but doing such a simple test doesn’t ensure that the device is capable of handling all possible error conditions or that it can be used across all possible international phone systems. Interoperability tests should be designed to exercise as many of the capabilities of the implementation as possible.

Conformance testing requires considerably more effort, both in designing and conducting the test. Even a simple standard could have hundreds of test cases. Certainly the conformance test for the electrical plug used in the example above could be quite simple, but the test for the fax machine, with the various protocols and error conditions that must be supported, could be quite extensive.

Given the advantages and disadvantages with both interoperability test and conformance testing it may be wise to do both, as these two types of tests are very complimentary with each other.

How are the tests created? It is usually up to the members of the technical committee, the developers of the specification who are the real experts on the topic, to specify tests as part of or to supplement the specification. Taking on this additional work will aid greatly in promoting the adoption of the standard. In some cases a third party testing expert will develop tests, either independently or in cooperation with the technical committee. The cooperative method is probably the best way to proceed with this, as the members of the technical committee are the domain experts, and the third party test developers are the experts on how to develop and conduct tests.

Finally the question remains as to who will conduct the test, track and judge the results, and provide a Certification of Compliance. In many cases it will be up to the implementer or manufacturer to self-certify; the manufacturer certifies that the product conforms to the standard but there has been no verification of these results from an independent third party. Sometimes the standards body who developed the specification will provide testing, but generally organizations such as these tend to shy away from providing this service. Despite the advantages with regards to promoting adoption of the specification and the possibility for establishing branding around the standard, there are legal liabilities associated with providing certifications.

The highest level of testing is usually provided by independent third party labs who specialize in this service; they have the most experience with developing and conducting tests, and are also set up to assume the legal liability associated with certifying compliance with a specification.

When it comes time to choose a chairperson for the technical committee or workgroup, how do the members go about doing so? Given the importance of the work to be done, the possibility of loosing an important one-time opportunity if the work isn’t done correctly, and the oftentimes large cost of the effort, the committee should choose carefully.

The chairmanship should not simply go to the first person to volunteer, or to the representative of the largest 800 pound gorilla in the room. In most group situations a leader will naturally emerge, but even then the committee members should take into account the desirable traits of a good committee chair, remembering that they may very well be stuck with this person for two or three years.

The committee members (or whoever else may be making the selection) should look for the following traits in the person who will act as the committee chair:

• Neutrality. The chair should be able to act on behalf of and for the good of the organization and the success of the technical work being done, rather than being influenced or directed by the agenda or strategies of his or her employer.
• Confidence. The chair should inspire trust and confidence from the committee membership.
• Time. The chair must have the ability (and permission from his or her employer) to devote the sometimes large amount of time required to do the job.
• Parliamentarian. The chair must have the ability to understand, implement, and enforce the organizations’ process, act as the organization’s representative in the business of the committee, have an understanding of and an ability to conduct basic parliamentary procedures, and have the ability to conduct a meeting.
• Take Direction. The chair must be willing to take direction from the organization’s technical coordinating committee and from the secretariat.
• Leadership. The chair should inspire the committee’s members to achieve a common, though sometimes difficult, goal, and have the ability to keep the committee moving towards completion of its mission in a timely manner. The ability to “herd cats” is very important in this job.
• Diplomat. The chair must have patience and the ability to handle difficult political situations, make difficult decisions, and achieve consensus among sometimes bitter rivals.
• Fair. The chair must be fair among all participants, and know when to bend the rules vs. when to follow them strictly in order to follow the spirit rather than the letter of the law.
• Conscientious and Organized. The chair must be thorough and detail oriented, and have the ability to set meeting agendas, give adequate advance notice of meetings, and track action items, meeting minutes, and decisions. (While the chair will oftentimes be assisted by a secretary in these tasks, they are ultimately the chair’s responsibility.)
• Spokesperson. The chair must have the ability to speak on behalf of the committee at conferences and with the press, within the bounds set by organizational policy.

You probably remember the thrill of buying your first home after college, or perhaps your first new car. For most of us, they were what you would call a “starter home” or an “entry level car”. They met your needs, and they were within your somewhat limited budget. But over time, as your needs increased – a couple of children, perhaps – and your budget allowed, you traded up and got a bigger house or a nicer car. And at some point you decided that it was worth a few extra dollars to splurge on some luxuries – some nicer furniture or a bigger TV – rather than having to make do with just the necessities.

A growing, maturing standards organization is a bit like that. How so? Well, the organizational structure, technical infrastructure, and technical process that worked fine for a startup organization with a couple dozen members and a committee or two will be stretched to the breaking point when the organization grows to hundreds of members and dozens of committees.

Here’s a few things that the organization’s leadership should consider, probably on an ongoing basis, as the organization grows:

• Is the mission and scope of the organization keeping pace with developments and movements in the market? Does the market still need standards for widgets, or has it moved on to thingamajigs or doohickies instead? How should the organization track these market changes, and how should it respond to them?
• What is the composition of the organization’s membership? Is it e.g. too heavily vendor focused? Does the organization want to achieve and maintain a mix of interest types, e.g. include users and implementers as well? What does this mean with regards to the organization’s recruiting and business development efforts?
• Is the technical infrastructure that the organization provides its members sufficient? Do the members need more than just a web page and email lists to do their work and make efficient use of volunteer resources? Should the organization consider providing functionality such as document management, electronic balloting, comment tracking, membership rosters, etc.?

There are also elements of the organization’s technical process that should be updated. The process document is the “rules of the game” that defines how a technical committee or working group is organized, operates, and develops and approves work. The organization should revisit tis process on a regular basis, and consider doing the following:

• Technical committees or working groups should justify their continued existence on some regular basis, perhaps annually. Is the committee making progress towards accomplishing its mission? Does it have a current list of and schedule for deliverables? Has the scope and/or deliverables changed over time? When will the committee know when it has completed its work and that it is time to close?
• The organization may wish to separate the observers from the active participants within larger committees. In any group of a hundred there will be a small number, perhaps just a dozen or so, that are actually producing work, and the rest are there just to watch. The active participants should be moved to a subcommittee where they can do their work, and report back to the entire committee for review and approval.
• As the number of committees in organization grows beyond just a few the organization should establish an oversight/coordinating committee. Even if the organization has a secretariat or standards administrator who is ensuring compliance with the technical process, there will be a need for technical oversight to make sure that the committees are staying on track with regards to their scope and mission, and especially to ensure coordination between the committees with some amount of overlap.
• As I wrote in a previous blog entry the organization should revise the technical process document to document more of its own procedures rather than relying on references to Robert’s Rules of Order.
• Committees should work on providing “the complete picture” with regards to their specifications; this includes developing compliance or certification tests, sample implementations, etc.

I’m sure that you’ve heard the saying “The best thing about standards is that there are so many to choose from.” The same holds true with regards to standards organizations; there’s a lot of them out there. Given the numbers, it’s certain that there’s going to be a lot of overlap in the work that the various organizations are doing. Even organizations dedicated to a specific vertical industry will overlap with organizations in other industries; for example, the use of XML-based e-business standards in the manufacturing sector.

Given this overlap there’s a need for the various standards organizations to be working together to prevent duplication of work and to promote interoperability between the resultant work. The means and form of this relationship can vary considerably based upon the situation and the needs of the respective organizations. Let’s look at a few points along a spectrum of how organizations can work together.

1. Communication. The simplest way that an organization can work with another is to simply communicate the nature and status of the organization’s work, so that the other organization can avoid duplication of effort and take advantage of the work being done elsewhere. (I wrote about this in a previous blog entry.) This leads to …

2. Referencing other work. The specification being developed by the organization should make normative or non-normative references to other organizations’ specifications. This promotes interoperability across a wider range of applications. For example, rather than coming up with a new syntax for date/time you should refer to ISO 8601, or to IETF RFC 2119 for keywords.

3. Cross participation. If an organization is interested enough in the work being done elsewhere, or especially if it has specific needs for which it wants a solution to be included in the other organization’s specifications, it should send its representatives to participate in the other organization’s committee. The representatives could be paid technical staff, or more likely would be one or more of the volunteer members of the organization. If it is one of the volunteers, the organization sending the person should be specific about whose hat the person is wearing (the organization’s or the person’s employer), and what their specific duties and responsibilities are (e.g. “your mission is to make sure that X is included in the specification”).

4. Establish a Liaison. In combination with or separate from the above, the next step is for two organizations to establish a formal or informal relationship. We see this sort of thing happening all the time; just look around at all of the press releases. My biggest objection to most of these is that there are no specific goals for the relationship; in many cases the relationship is in the form of a “mutual admiration society” where the parties state that they acknowledge the importance of each others work, promise to work together, they’re going to be best friends forever, blah, blah, blah, etc. For the relationship to mean anything, though, there should be specific goals and/or deliverables, e.g. they will work cooperatively to accomplish X or will jointly develop Y. This could lead to …

5. Cooperative efforts. In some rare cases two organizations will actually cooperate on the development of a single specification. So rather than simply sending representatives to participate in each others’ work, as in #3 above, there are actually two committees, one at each of the organizations, working on the same specification. This sort of effort is rare because of the issues involved: How do the two committees communicate with each other? (There could probably be significant overlap in membership.) What if the two committees can’t agree and start taking the specification in different directions? Who owns the resultant work? (It could be jointly published.) Which organization’s process will be used to approve the work first? or will approval take place simultaneously at both? And, if the latter, how do you handle comments received during the review phases? Etc. None of these issues are insurmountable, as proven by the recent success of the OASIS/W3C joint effort on WebCGM. The key to success is to establish the ground rules in advance, and to sign an agreement covering the issues related to process, participation, and ownership.

6. Submit for Approval Elsewhere. Finally, organizations can work together by one organization’s submitting its completed work to another organization for approval under the other’s process. This is happening with increasing frequency, as we see with examples such as OASIS submitting its ODF standard to JTC1 for approval as an ISO standard, or Microsoft submitting OOXML to ECMA who in turn submitted the specification to JTC1. There may be a need to negotiate ownership and future maintenance responsibilities under such a process, and usually the organization to whom the work is submitted will want to accredit or somehow approve the process under which the work was initially developed, and some sort of formal relationship is usually required to be established before work may be submitted.

In my previous blog entry on parliamentary rules, I suggested that Roberts Rules of Order might be a bit heavy for standards committees and that committees should attempt to use consensus as their first level of decision making.

What is consensus? It’s not necessarily where everybody agrees; that’s unanimity. And it’s not necessarily a majority position either; that would be more determined by the voting as defined in parliamentary procedure. The dictionary defines the word “consensus” as a general agreement. This isn’t terribly specific and wouldn’t stand up to an appeal, so the organization using consensus as part of their process should provide a more exact definition and define the process for determining when consensus has been achieved.

A number of standards organizations have made this work, and have done so by explicitly defining what consensus is and how it is used as part of their procedures. Let’s look at a couple of these.

An early slogan of W3C standardization efforts was “rough consensus and running code”, and consensus continues to be an integral part of their process. In section 3.3 of that document it says that “Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them…”. Further, consensus is defined as “A substantial number of individuals in the set support the decision and nobody in the set registers a Formal Objection.” And finally (in section 3.4) “A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed, and that a vote is necessary to break a deadlock.”

At the IETF, the process is consensus-based as well. The IETF Working Group Guidelines and Procedures states that “The core rule for operation is that acceptance or agreement is achieved via working group ‘rough consensus’…. A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair(s) to manage the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group’s goals and objectives.”

The same document further defines the means to achieving consensus. “Working groups make decisions through a ‘rough consensus’ process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail.  (However, it must be noted that ‘dominance’ is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as “rough consensus” and 99% is better than rough.  It is up to the Chair to determine if rough consensus has been reached.”

Ah, the famous humming…

So at W3C consensus means that nobody disagrees strongly enough to want to make a fuss about it, and at IETF the working group chair is given the authority (and responsibility!) to determine when consensus has been reached. Two different methods, but both workable. The lesson is that the two organizations have defined what consensus is and how to reach it; I suspect that leaving undefined such an important yet nebulous concept as “consensus” would not have been as successful.

I’ll bet that buried somewhere in your standards organization’s bylaws or technical process is a line stating that Robert’s Rules of Order will be used to govern the discussions and decision making in the organization. And I’ll bet further than no one in the organization knows what that really means. Robert’s Rules of Order (RRO) is a pretty complex set of rules, and a lot more baggage than most organizations need. RRO generally gets inserted into the process as an afterthought or catch-all, or because someone thought that that’s just what ought to be done. And generally Robert’s Rules of Order is referred to even though Robert’s Rules of Order Newly Revised is the latest version.

Most people have a general idea of how parliamentary procedure, as defined by RRO, works. They know that a motion must be moved and seconded, and many also understand that further discussion then takes place before a vote is called. And a good chair can usually handle the intricacies of nested motions reasonably well. But who really understands when a majority is required, when a supermajority is required, what constitutes a quorum, and which motions take precedence over others? How many times have you heard someone calling “point of order!” when they merely want to make a speech?

Don’t get me wrong; I’m not criticizing RRO. I’m just suggesting that by saying that you’re going to use RRO you’re committing yourself to using one of those huge 100 ton dump trucks they use in strip mining, when all you really need is a garden shovel and wheelbarrow. The phrase “right tool for the job” ought to come to mind. If you need to haul a lot of dirt use the big truck, but if you don’t then use the wheelbarrow. If you really need RRO then use it, but if not look for something a bit more light weight that might fit a little bit better.

Many organizations just starting out will define a small number of things in their process and then refer to RRO for the rest, then as they grow and their process matures they will define more and more things for themselves and rely on RRO less and less. That’s where you want to get to, but depending so heavily on RRO that early process may be burdensome.

Let me suggest an alternative. There are other parliamentary procedures that are more modern and lighter weight than RRO. A web search for “parliamentary procedure”, or a book search for the same phrase on Amazon, will get a lot of hits. The Standard Code of Parliamentary Procedure from the American Institute of Parliamentarians might be worth looking at.

Generally, though, I usually consider a set of parliamentary rules something to fall back on only when required. Most committees work well this way: the meeting is mostly informal discussions and suggestions, and only when things get a bit heated, or when a formal decision is required, does the chair revert to using parliamentary procedure.

So how do you postpone having to use parliamentary procedure, i.e. how do you keep the meeting informal and friendly as long as possible? Usually the answer is to seek consensus, and only when that is not possible would the chair dig out the gavel. A number of standards organizations have made consensus an important part of their processes with good results. More on that later.

Earlier this week I wrote about getting users involved in the standards process. A speaker at the Yale symposium suggested that it just wasn’t practical to actually get users participating on the technical committee or work group, but that efforts should be made to gather user feedback, that user advocacy within the committee would be the solution.

While I agree that user advocacy would be better than nothing, that the committee should be proactive in getting user feedback into the committee’s work, I would like to propose a better solution, that the standards organization could in fact get user participation if it made the effort to do so.

(For the purposes of this discussion, I’ll assume that we’re talking about consumers, the guy on the street, and not the large company users that can afford to send its employees as representatives to participate in the committee’s work.)

First, what are the obstacles to getting users (consumers) involved? On the assumption that the work of the committee is something that users would care enough about to want to provide input for, the first obstacle is the user not knowing about the work. Second, if the user knows that the work is being done, does he or she know that users are welcome and encouraged to participate, and how to get involved?

And what about the costs of participation? The user may care about the subject but perhaps not enough to want to pay money to participate, and even if she did care enough certainly wouldn’t be able to afford corporate-level dues. Face to face meetings in various locations requiring travel, especially when occurring on a regular basis, would be impossible, and since most of these prospective participants will have day jobs, telcon meetings during business hours would make participation difficult.

None of these obstacles are insurmountable for the standards organization that truly wants to get users involved in its activities. The solution to the problem of users knowing about the project and how to get involved is, of course, publicity. This may be a new thing for some standards organizations, publicizing or promoting activities outside of their current membership, but an effort that they should consider if they want to reach out to a broader audience. A key to this is not just announcing the activity, but also soliciting participation and telling interested parties how they can get involved.

The organization needs to back up this solicitation for participation by making it simple for interested parties to participate. A low (or no) cost membership or participation fee should be made available. This would probably be linked to a lower level of benefits within the organization, but a user/consumer usually wouldn’t care about anything beyond the ability to participate.

The organization should also consider how to structure this level of participation: would the users be full-fledged members with all participation and voting rights, or simply members of a requirements-gathering forum? Company members paying hundreds of thousands of dollars to send their highly-paid employees to participate may not appreciate being out-voted by a group of unpaid members.

Finally, the organization should provide a technical infrastructure that supports low costs of participation. Electronic web-based tools such as email forums, document repositories, collaborative editing environments, web forms for collecting and managing comments, electronic balloting, etc. will all provide for remote participation outside of business hours, allowing any interested person to participate in the development of standards that will affect him or her.

At the Yale Law School OSIS symposium last weekend Ken Krechmer of the International Center for Standards Research spoke on the topic of Open Standards, i.e. what makes a standard open. (See his position paper here.

Ken pointed out that most standards problems are solved by the use of open interfaces, and suggested as a metaphor the common building brick. Bricks, while usually made from red clay, could actually be made from any of a number of materials and by any of a number of manufacturing processes. What’s really important about the brick is its size and shape; it must be the same size and shape of other bricks being used in building the same wall. A brick manufacturer is free to change the chemical composition of the materials, or use an innovative process to form or bake the brick, as long as the resultant brick is the right size and shape.

We can consider the size and shape of the brick, i.e. the interface, to be a standard. Further, we can specify that some parts of the standard are required and others optional; with regards to the size and shape of the brick, only the height is strategically important. We also see that the brick manufacturer is free to innovate with regards to manufacturing the brick as long as the interface standard is met. (Yes, there will probably be other standards for strength and durability, but let’s keep this simple.)

A common complaint about standards is that they limit innovation. In some respects, yes, but in other respects standards can encourage innovation. How so? Continuing with Ken’s brick metaphor, if the standard size and shape of bricks were not standardized, i.e. if every brick was different, the bricklayer would have an extremely difficult job. So that type of innovation needs to be restricted. Since the manufacturer doesn’t need to devote resources to coming up with new sizes and shapes, because that much has already been decided, the manufacturer can devote its R&D efforts towards the manufacturing processes. And further, because bricks are easier to use because they are all the same size, bricks will be used in more construction projects, increasing the size of the market and the manufacturer’s revenues, allowing further efficiencies and innovation.

The history of industrialization is full of such examples. The move from hand-built (the original definition of the word “manufacture”) to mass production led to job specialization, more efficient processes, and interchangeable parts. Standard railroad track gauges allowed trains of different companies to travel on each others’ tracks. The telephone, fax machines, radio, cell phones, email, steering wheel on the left, 110v, shipping containers, threads per inch…. all are based on the idea of standardizing the interface in order to allow for efficiencies in use, freeing up the manufacturer to innovate in other areas.

Standardize on the interface, and innovate on the functionality.

Over the weekend I attended the Open Standards International Symposium (OSIS)  hosted by Yale Law School. The symposium included speakers from around the world speaking on the subject of open standards as they relate to technology, economics, politics, and law. I’ll blog on a few of the topics presented over the coming days.

This blog is mostly about best practices in standards setting, so I’ll start by mentioning a presentation by Vittorio Bertolo, CEO of Dynamic Fun and a member of the ICANN Advisory Committee. He points out that 40 to 60 percent of internet users are now publishing content of some sort, and that internet standards are no longer just for engineers. As such, it is important to involve the users in the definition of standards.

This has always been the case – or at least should always have been the case – that user’s needs should be taken into account when standards are developed. “Open Standards” usually means that all interested parties have a voice in the development of the standards, and well run standards organizations usually attempt to have a broad, balanced representation of interested parties in the effort. ANSI’s Essential Requirements for accredited standards developers say that a broad representation of interested parties in the standard effort should be sought. But how often are end-users actually involved in standards committees?

It’s normal for representatives of large companies to sit on standards committees, and occasionally those large companies are acting in the role of users. For example, a large company could purchase and deploy large amounts of IT infrastructure, or their employees could be users of large numbers of laptop computers. In such cases Large Company, Inc. is indeed a user.

But how often does the ordinary consumer, the guy in the street, Mr. and Mrs. Average Joe and Jane, participate in the committees that set standards for the products they use? Oftentimes they don’t care; as long as their cell phone works they don’t care about the details of the hundreds of interoperating standards that allow a call to go through. But what about the standards that they do care about? For example, were any consumers consulted when digital rights management (DRM) standards were being defined? or were these standards developed solely with vendor and content owner input?

There are obviously a number of obstacles to their participation, including knowing that they can participate, knowing which committees to participate in and how to do so, and of course the minor detail of having the time and money to participate in meetings. Further, how many organizations would make such a person welcome on the committee?

Bertolo’s suggestion is that this isn’t practical; we wouldn’t expect to see the guy on the street participating. But user participation is not necessarily about representation, he says; it is about advocacy: users’ needs and feedback needs to be injected into the process without their having to attend meetings.

How do we do this? For starters, a committee beginning a standards project should start with use cases and user requirements. The specification should have one or more public review periods, and comments collected during those reviews should be taken seriously. And of course it helps that the standards organization publicizes the work of the committee to let the world know what is taking place so that interested parties can know to respond to the work.

Another presentation on the same program was by John Morris of the Center for Democracy and Technology. He points out that “public policy is being increasingly affected by decisions made within technical standards-setting bodies,” that the “public has little or no voice in these standards bodies,” and that public interest organizations don’t know how to participate or don’t have access to participate in the organizations developing standards influencing us all. Morris suggests as well that the solution must include public reviews of draft specifications, the standards organization being receptive to input , and that “public policy considerations raised by a proposed standard are identified and assessed early in the design stage.”

Andy Updegrove has been keeping a close eye on OOXML and commenting on its movement through submission by Microsoft to ECMA, then ECMA’s approval and submission to JTC1. His blog entry this morning focuses on some problems with the JTC1 approval process, in particular the definition of the word “contradictions”.

At this stage of the JTC1 fast track approval process, after a specification has been submitted by a JTC1 liaison (in this case ECMA), there is a 30 day period during which the JTC1 member national bodies may identify any “contradictions” related to the submitted specification. The problem is that the JTC1 process doesn’t define what that word means and how it should be used in the context of the process. Generally it would mean a contradiction between the work under review and any existing international standards. Microsoft, the developer of the specification, and ECMA, the organization which approved it under their process then submitted the work to JTC1, are suggesting a very narrow definition, while opponents to the approval of OOXML as an international standard are suggesting a much more broad definition and are submitting hundreds of items for JTC1 to consider.

My reaction after reading Andy’s article? Bad process. Bad, bad process. Go to your room without any supper.

Well, maybe that’s a bit harsh. It’s not so much a bad process as a process with certain weaknesses. As I’ve suggested before perhaps JTC1 needs to take a look at revising its fast track approval process. I believe that it is dangerous to accept into the fast track approval pipeline a specification that was developed under a closed process, i.e. by a single vendor; perhaps requiring multiple implementations from different companies should be required. And now we discover that the process for reviewing the submitted work is not well defined.

JTC1 created the fast track process to accept specifications approved by other organizations as a way to recognize the merit of work developed and approved by non-accredited consortia. I wholly agree with their intent, and applaud their recognition of the high quality of work generally done by these organizations. However, the process appears to be a bit too streamlined. Not with regards to speed — the review and approval takes six months — but rather the things that are checked during the review. The process has worked so far, and numerous consortia specifications have gained international recognition through this process. But the process is perhaps not robust enough to handle a controversial submission.

I suspect (and hope) that after OOXML is either approved or rejected that JTC1 will revisit its process and make revisions to prepare for future events such as this.

The lesson to be learned is not just for JTC1, however. As I work with consortia and other standards organizations, especially those just starting up, there is often the feeling that “good enough is good enough” when it comes to a technical process, that a few simple guidelines are sufficient, that the participants in the consortium’s activities all get along with each other and have common shared interests. “Let’s not worry about the politics; everything will be fine”, they say. But that’s not the way things go. Eventually a situation will arise where there will be conflict and misunderstanding, and having a robust process defined in advance will be all that separates success from chaos. Could you imagine a professional football league, with all the money that is at stake there, using a single page of scribbled notes as the rule book? How is the development and approval of standards any different?

The best way to avoid uncomfortable and difficult situations in the standards world is to define a thorough, robust, and fair process in advance; otherwise we all get to play Calvinball.