For much of my 40 year career, the development of standards, both IT standards and those of other fields, proceeded in much the same way. A group, often under the guidance of a national or international standards organization, would work out a proposal, pretty much in private, and submit it to a series of reviews by other people interested in standards. The process under which this happened was quite formalized and participation was rather limited. Though the process worked, it was originally designed for a time when communication was by mail and it often took a long time to conclude.
The Internet, e-mail and other social technologies have changed how we communicate. Experience with software development has changed how we organize and realize projects. Communication is immediate (and often continuous) and software is constructed using agile methodologies that break the work into relevant chunks that are realized in succession (rather than trying to do the whole project at once and then test and deliver – i.e. the “waterfall model”). It is time that standards development, at least for IT standards, exploits these cultural changes to make the standards development process more effective.
The World Wide Web Consortium (W3C) has undertaken updating its process to allow more agile standards development. Over the last five years, the W3C has opened up much of its standards work to public participation on a daily (if desired) basis. But, there are aspects of the current W3C Process that act as barriers to more agile standards development. One of these is the assumption that all parts of a potential standard will progress at the same rate; that is, all parts of a standard will be accepted and reach deployment at the same time.
In the past, a specification would go through a number of public Working Drafts, become a Candidate Recommendation and finally a W3C Recommendation. When the relevant Working Group believed that they had completed their work on the specification they would issue a Last Call. This Last Call was a request for confirmation that the work was complete by people outside the Working Group. All too frequently, this Last Call was both too late (to make changes to the overall structure of the standard) and too early because many relevant detailed comments were submitted and needed to be processed. This led to multiple “Last Calls.” When these were done, the next step, Candidate Recommendation, was a Call for Implementations. But, for features that were of high interest, experimental implementations began much earlier in the development cycle. It was not implementations, but the lack of a way of showing that the implementations were interoperable that held up progression to a Recommendation.
So, the W3C is proposing that (where possible) standards be developed in smaller, more manageable units, “modules.” Each module either introduces a new set of features or extends an existing standard. It’s size makes it easier to review, to implement and completely specify. But even the parts of a module mature at different rates. This means that reviewers need to be notified, with each Working Draft, which parts are ready for serious review. This makes the need for a Last Call optional. It is up to the Working Group to show that they have achieved Wide Review of their work product. This involves meeting a set of reasonable criteria rather than a single specific hurdle. With this change, Candidate Recommendation becomes the announcement that the specification is both complete and it has been widely reviewed. This is the time at which the final IPR reviews are done and the Membership can assess whether specification is appropriate to issue as a Recommendation. It is also time that the existence of interoperable implementations is demonstrated.
With these changes, it becomes much easier to develop all the aspects of a standard – solid specification, wide review, implementation experience and interoperability demonstrations – in parallel. This will help shorten the time from conception to reliable deployment.
Sr. Computer Scientist