This is a revolution in standards I'd like to see but don't expect in my lifetime.

Someone on the de-centralization list said "Standards shouldn't be built by amateurs". Well frankly the professionals have made a complete and utter hash of it. For a variety of vested interests, the standards we're trying to work with are either broken or have grown so vast that they might as well be. Or there are an infinite number of standards to choose from, so they're not really standards are they.

Stand back, try and hide your own emotional attachment to any one of these and take a look.

  • HTML. We still can't agree on what it is. Why do we even need a campaign for conformance.
  • XML. Have you seen how many entries there are in the alphabet soup?
  • RSS. At least three competing standards for the same area of XML headline syndication.
  • RDF. Make the standard infinitely extendible. So where's the standard?
  • XML-RPC. Almost "good enough", but inherently brittle.
  • SOAP/WSDL/UDDI. I need this in here. And this. And this. And this. How did the standard get so big that the BDG was even needed?
  • WAP. Let's re-build HTML for the telecoms industry. Like, Doh! WHY!!?
  • HDTV. Where is it? And why are there 3?
  • GSM, CDMA, G3, and all the other cellphone standards worldwide. What? Why are there so many?
  • Java. Which JVM have you got installed? Oh, that's the wrong one.
  • Perl. Check CPAN. See RDF.
  • Unix. Sorry, we haven't ported to that one.
  • Redbook CD. We just need to make a small change to stop you reading the data.

    Need I go on? The whole computing industry has been throwing rocks at the mirrors and wondering why they can't see themselves afterwards.

    But look at the TCP/IP standards and all the early RFCs. These are short, succinct, widely adopted, just plain work and have stood the test of time. They are the existence proof that it is possible.

    I think there's some lessons here about standards and how to contruct them so that they are successful. The following are all attributes that help.
  • Elegance. Short and succinct standards are more likely to be built.
  • Documentation. The documentation should be easy to find, short and simple. It should provide ample examples and be written from the point of view of someone trying to a) understand why the standard exists and b) implement something built on top of it. A management summary explaining how, why, when, where in a few short paragraphs is essential. Some real world use cases also help to explain why the standard exists and how it should be used.
  • Reference implementations. The reference is not necessarily supposed to be a perfect example, but it should at least be a proof of concept.
  • Stability. The standard should be stable for enough time to become established and upgrade paths clearly signposted. Ideally the standard should grow over time while still supporting earlier versions.
  • Resilience. Effort should be made to ensure that poor implementations are tolerated and don't break better implementations.
  • Validation. It's essential that implementors have something to measure their work against and check that it does actualy meet the standard.
  • Directory. At the earliest stage there should be a directory of both toolkit implementations and sites that support the standard in some real world way. Many standards can benefit from a machine readable file of the implementations and this should be included and considered early in the development.
  • Evangelism. The community of users needs to be nurtured. the standard needs sales and marketing just like any other product.

    [ << Technology Revolution ] [ CGI-RPC >> ]
    [ 0 comments ] [ G ] [ # ]