Standards are very weird. On way of talking about their weirdness might be to construct some sort of hierarchy of standards types. But really it’s more like a feature matrix. Your standards can be any and all of: de facto, de jure, intellectual property encumbered, easily implemented, impossible to implement, underspecified, overspecified, internally inconsistent, useless, and undeployable.
This particular observation was brought about by me trying to figure out how combine my paper bin with Dan’s PaperQ. (Aside: My paper bin is more of a paper queue, and Dan’s paper queue is more of a heap.) We want to take some sort of nice publication format, and allow others to download an easily parsed file that they can then use to see if they need to type in that damn BibTeX again. (BibTeX would be an example of a standard that is fundamentally sucky, whose only advantage is that we don’t have anything better deployed). Also, it would be nice if this system interfaced well with other systems for publishing, supported some notion of security, had tagged keywords (c.f. creativity), and was easy for nerds to hack support into their own personal scripts.
Well, I already knew about RSS, but Josh had mentioned that the guy in charge of RSS was a cranky guy who didn’t want to bog it down in specifications and that it was not extensible. So I looked around for ATOM.
My God.
ATOM is one of the most painfully overspecified bundles of poo I have ever dealt with. I leapt back, my nose aflame. That specification attempt stinks. People are having flamewars across an IETF working group and the spec is a hojillion pages long and includes things like post authoring and all sorts of other things that I neither want to deal with nor know how to deal with.
So back to RSS it is. I predict that ATOM will never overtake RSS, because the spec is simply too gross. Remember the old motto of the IETF, and avert your eyes from ATOM: “We reject: kings, presidents, and voting. We believe in: rough consensus and working code. — Dave Clark”
And if you are ever trying to do something new that needs to interoperate, try to let your standards follow the be-do-have approach. Work with a few people, get things to where they need to be to get your systems to work together, and every time you have a chance to remove complexity, remove it.
Perfect design of standards is achieved not when the thing can do everything, but when you cannot take anything away without losing the essence of the system. Always keep in mind YOUR requirements, and your friends’ requirements. Reject calls from people about hypothetical improvements – put in an options field and let them fight amongst themselves. Build your systems and protocols small and extensible. Make them like Firefox, not like Mozilla. Like TCP, not like ATM. Like HTTP, not SET. Like BGP, not like MPLS. Like Unix, not like Windows. Like C, not C++.
