Standards: Optional Features or Law?

March 19, 2003

Dimitris Dimitriadis

In an earlier article, I argued that providing uniform test frameworks and detailed specification formats would enhance interoperability of specification implementations. Technical issues aside, some of which I discussed in that article, there are a few important reasons why this is difficult: corporate politics, on the one hand, and standard organizations' inability to enforce standards on the other. How can we make sure the specifics of a standard are present in products which claim to implement it?

The Need for Standards

I don't think anyone would argue against the need for standards which state the way, for example, information should be exchanged, parsers should work, or infosets should be exposed. Consider the building industry, which needs standards for constructing houses: electricians and plumbers need to know what to install, what not intall, and how to do these things. The end user, in this case the person living in the house, needs to have some reasonable expectation that safety and other regulations have been taken into account and that, if regulations are ignored, the builder faces heavy fines. Fines are typically collected by governmental entities, that is, public organizations, since the process is incorporated into legal practices.

But since there is no public institution to inspect software construction, why do we even want standards? There are several reasons. First, we want to be sure that information is accessible. Without standards which require information to be accessible, companies have often invested more resources in differentiating their products than in fixing errors. In extreme cases, corporations have released software that is not compliant with standards which the corporation helped create to begin with.

Second, we want standards to ensure interoperability, which is not possible if every implementation has a different understanding of what it's supposed to do. Clearly, there needs to be someone who can absolutely indicate what is, and what is not, a successful implementation of a standard. This is the only way to ensure that product A implementing standard X does the same thing as product B implementing the same standard.

Third, we want standards to ensure that information is easily exposable. This is especially interesting in the cases where public information is stored in a way that requires particular software to access it. Exposing it through a web interface may not help, since a fully conformant browser may fail to show the information, if the web site producers have decided to write for the mainstream set of browsers in use (that are usually not conformant).

If there were clearly delimited conditions for implementing standards it would make writing interoperable software easier and, in some cases, possible. Without such a clear set of ways to proceed, almost anything goes.

Changing the Standardization Game

Having been an invited expert to the W3C, arguably the Web's most influential standard organization, over the past two years, I've more often than not seen standards reduced to merely words on paper and unimplemented features (or incorrectly implemented features).

One of the main difficulties is the inability of standard bodies to enforce implementation of specifications. The W3C works with consensus as a guiding principle. This means that, where possible, participants seek unanimity; where that's not possible, participants seek consensus (no one objects, some may abstain). In cases where neither of these is possible, the solution voted for is usually fairly weak. Furthermore, the W3C, does not aim at ensuring that specifications are correctly implemented, merely at producing them.

One possible solution would be to make sure that the initial involvement between a corporations and standards organization was of a more legally binding kind. That is, when signing up to participate in an activity aiming at producing a specification of a particular technology, a corporation promises that it will follow the specification. Failing to do so would be the equivalent of building a house of poor quality. It seems this is not as easily done as said, though, so one needs alternatives.

Another possibility would be to involve the public as much as possible. The way it currently works is by having companies represented in standard organizations produce specifications, that in turn get implemented in software. Given a greater understanding of the strategic importance of quality, testing has become an integral part of this activity. However, testing is not necessarily done in public, which means that normal users (and developers) do not always get a chance to react to various situations until well after the fact. This, in my opinion, would need to be remedied.

Fighting Corporate Politics

I believe that standard organizations should have more power over what implementations can be claimed to be conformant. One way is to provide, in addition to the specifications themselves, testing material used to assess the quality of implementations. This is, to some degree, done already, as you can see by visiting the link to W3C testing technologies. Another, stronger solution would be to initially make it clear that companies participating in the standardization activity commit to follow the standards. This could be done in a legal document, stating what the effects of not doing so would be. Third, the public could be made a more active part in the standardization activity, by testing and providing feedback (by public here I mean end users, but also organizations representing specific user groups, such as visually impaired people).

This presupposes, though, that there is an organization which makes sure that things are done right. Seeing that corporations are (generally) not favorable toward this, it is up to the rest of us, our governments, and similar control mechanisms to make it happen. Think of it as a bill of information technology rights.

One way of dealing with these issues would be to change the agreement between the corporation/organization participating in the standardization process and the standards organization itself. Standards organizations should typically make it very difficult for companies to release software that is clearly non-conformant, especially where the technology it relies on is specified in activities in which the corporation takes part.

It is, at best, very difficult to achieve this, since there is no organization that could enforce correct use of standards. I think one should concentrate on something different while waiting for a new "contractual" situation; in other words, have users exercise their right to standardized implementations using test tools now being made available.

The Public's Responsibility

Developers are not only producers of software, but also consumers. Seeing it that way helps set priorities. It should be difficult for corporations to release poor quality software (as far as implementing standards is concerned). One easy way to check and implementation's quality is to use conformance test frameworks (for W3C specifications, you can find tools on this page). Similar tools exist for other types of specifications.

So what should we, as developers, do?

• If bodies are open to the public, stay tuned to the public mailing lists for comments/feedback. Require that information be released to the public at regular intervals and in understandable form. Read it thoroughly (since people have invested time and resources in producing it) and provide constructive feedback.

• Once test suites are available, use them to test implementations and report results (either to the public mailing lists or to the implementor directly). Add to the existing bulk of tests to make sure that all parts of the specification get tested. Test, test, test. And make results available. Shout about it. Write fancy presentation engines for publishing results. Get in touch with organizations for which these results are relevant (for example, organizations for the visually impaired). Team up. Make a buzz.

• Require that it be made possible to use test material for implementations, not accepting the license claims sometimes made (this means, read what you click "OK" for, and if you don't like it, propose a change to the implementor). If it is still not possible to publish test results for a particular implementation, tell your friends to run the tests themselves, to avoid being illegal.

• Become involved in producing alternative implementations that implement the specification, have them tested, and report the results. Make sure you pay respect to the specification you were about to implement, and make it easily available.

• Educate the public. Tell people why this is important. This can be your friends, colleagues from another department, or just people in general. Have them understand what can be gained from standards compliant software.

Up until now, we have the lacked tools to assess the standards compliance of software. Therefore, it has been fairly easy for implementors to release software which is of poor quality, and market it in such a way that it becomes predominantly important in the market, thus achieving de facto standard status. The time has come to make a change and make this a mature business. The easiest way to do this is to use test materials being made available to make sure things are right. No one needs to spend every working hour on this, but many people doing small things can improve the situation.

Testing for Standards Compliance is Important

Why is compliance testing important? Given the increasing importance of information in our everyday lives, you want to make sure you know what's going on. It's also about simplifying your daily job. Wouldn't you just love having a simple set of features to implement and know that your code would be cross-platform, instead of writing four versions for an equal number of platforms (and test, document and maintain them separately)? Also, exercising power in a constructive manner is a very good way of ensuring quality, which in the end we all gain from.

As we are currently lacking a body which can assess conformance claims, and also waiting for a new kind of agreement between participant and convener in the standards business, we need to make sure that things have been correctly implemented ourselves. Having gained this knowledge, it can be transferred to customers, colleagues and friends. Ideally, even marketing people will come to understand why this is important. In turn, and given large enough numbers, this will certainly bring about a change in the interoperability arena, making it more difficult for non-conformant implementations to be marketed as conformant. I for one would like to see that.