Standards: Optional Features or Law?
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.
How do you think standards compliance could best be enforced? Do you agree that strict enforcement is best anyway? Share your opinion in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Enforcing standards
2003-03-27 07:26:17 Lance McKee [Reply]
I invite you to see what the Open GIS Consortium (OGC http://www.opengis.org) does. Specifications are drafted in testbeds sponsored by major users, usually federal agencies who bring their requirements. The key to commercial implementation of the specifications is in boilerplate standards-demanding language in government requests for bids and proposals at federal, state and local levels. Such language also needs to be written into grants from higher levels of government that may pay for software and data procurements by recipient agencies. This "procurement language" initiative is not really off the ground yet, but it has wide support among user members of OGC. OGC focusses on interoperability between geoprocessing systems like GIS, earth imaging, facilities management, navigation and location services. MUCH publicly paid for data in this domain is (or was until OGC succeeded) locked into proprietary systems.
Lance
- enforcing standards
2003-03-21 01:21:25 bryan rasmussen [Reply]
a standard that is declared to be one without any widespread implementation is dead as far as I can see. What about a standard that would have a good chance of dying if not for the fact that a bunch of other living standards are forced in version 2 to rely upon it? If companies that have a stake in implementing version 2 of standard X are forced by this stake also to implement version 1 of standard Y then I submit that enforcing standards in such a scenario would have the effect of slowing down progress. Of course we know that W3C would never build or force such an interlocking mess upon the community, so this post smacks somewhat of alarmism at the otherwise wholly laudable ideal of enforcing standards.
- Standards Should *NOT* be Enforced
2003-03-20 13:35:03 Peter Herndon [Reply]
I detect a large helping of standards-itis in this article, perhaps generated from the author's position in the W3C. I contend that, while standards testing is a *very* good thing, and that standards compliance labels should very much be awarded by the standards body to recognize levels of compliance, the W3C has made a very arrogant mistake in its approach to standards and enforcement.
Standards are a good thing. I do not deny this fact. However, a standard is not something that arises a priori. A specification arises a priori, but not a standard. A standard is a way of doing something that has been adopted by the community as a whole (preferably based on its merits, though occasionally not). In the W3C, I see the generation of forward-looking specifications that have been given the label "standard" without any community consensus. And no, the community of self-appointed experts who are on each working group does not constitute the entire community of developers and users.
Please understand, I am not attacking the work of the W3C, as I think that much of it has a great deal of value. I am, however, attacking the contention that what the W3C produces should rightly be called standards, and the fundamentally arrogant attitude held by the W3C regarding enforcement, as exemplified by the article.
While the W3C has been very busy generating what I think of as specifications, specifications that very frequently have immense technical value if adopted as industry standards, it seems to me that it constantly falls prey to putting the cart before the horse. Uptake of XML, for instance, is due to the inherent value that people saw in having a common means of defining the syntax and semantics of text markup. The need for a solution arose, W3C came up with a specification for a solution, people saw it and liked it, and now XML is widespread. The W3C maintains the definition of the specification, and individual groups either adhere to this definition or not. And thus, those who do so adhere have a means of interoperability and common tools that would otherwise mean custom development or be completely denied them.
But that's the fundamental point -- what the W3C produced is a *specification* rather than a standard. It *became* a standard through widespread adoption, due to its innate usefulness. The takeaway point here is that standards cannot be enforced, because if nobody uses a specification, it is NOT a standard. Look at HTML for this -- W3C has produced several specifications for HTML, and while individual documents can be validated as complying with the specification, no user agent of which I am aware meets all the applicable specifications. Some come close, while others disregard the specifications and implement recognition of tags that don't exist in the specs. And *all* of them (except, I suppose, Amaya) implement a variation of "quirks" mode.
So, when folks from the W3C argue that standards should be enforced for the good of humanity, or at least the good of computing, my hackles instinctively raise. How can the W3C arrogate to itself the one true vision of how something is supposed to work? All it *should* do is promote awareness of its specifications and reward with some official notice those who do comply. And the same is true for all guardians of standards.
Again, I am not attacking the W3C's technical competence on the whole, nor am I attacking the value of adhering to public standards. I simply dislike the overbearing posture exhibited by articles such as this. It isn't a standard if nobody adheres to it. Adherence should be voluntary and due to the advantages of using the standardized specification.
Okay, maybe I'm just grumpy and this gets my back up a bit...
- Standards Should *NOT* be Enforced (Author's reply)
2003-03-20 15:15:07 Dimitris Dimitriadis [Reply]
The contents of the article should *not* be wrongfully attributed to the W3C. My liaison with this organisation is as an invited external expert, not as an employee. The views expressed in the article are my own.
/Dimitris Dimitriadis
- Standards Should *NOT* be Enforced (Author's reply)
- Law: german law
2003-03-20 02:16:51 Reinout van Rees [Reply]
From what I remember from an article in a recent iX (highly regarded German computer magazine): it will soon become law in Germany for government agencies to adhere to the w3c's standards for html and css, including a large part of the accessability guidelines (for the blind etc.).
This 'll undoubtedly have its effect on other businesses in Germany as well. In my opinion this is a very good step forwards!
See http://www.w3.org/WAI/Policy/#DE for a link.
Reinout van Rees
