Should Atom handle today’s problems or tomorrow’s?
by ZetaGecko | Add Your Comments | Atom/RSS
Atom is the outgrowth of a number of people's desire to fix several problems of the RSS specification. Because those exercising influence in the RSS community were not open to the kinds of changes being proposed, a new format was created. If you're reading this, you probably already know that, but here's the point: Atom was created to solve today's problems. As the effort to define Atom continues, questions periodically arise over whether a particular feature is needed. It's partly a question of whether a lot of people will use the feature, or only a few, as I've discussed before. But it's also a question of whether a feature is needed to enable people to do things they want to do today, or whether it's a feature that people may need to do something they may need to do someday.
While the idea of creating a format that can do anything anyone may ever want to do has it's charm, it is possible to create formats that are so complex that they don't get widely used. A historical example is SGML. I don't know a lot about SGML, and there probably are plenty of people who use it, many many more people use HTML and even XML, both of which (if I'm not mistaken) could be described as simplified versions of SGML. Their relative simplicity has lead to much greater adoption, despite the fact that they don't do everything SGML does. It's better to be able to do enough than to be able to do too much.
But how much is enough? How should the Atom community decide which potential future needs to meet, and which to leave out? Or should they focus only on present needs? One part of the answer is that possible future features should be discussed so that the current version of Atom can be designed in a way that will make its extension to support additional features later as easy and clean as possible.
Another issue that should be considered is the difficulties that might arise if a feature that is excluded from the spec is independently developed as an extension. If the extension is poorly defined, but manages to get widely deployed, then where do you go? Do you create a better-defined, competing extension? Do you create a new version of Atom with a better way of supporting the same feature? Or do you just suck it up and support bad extensions? This is starting to sound like the whole RSS 1.0 vs RSS 2.0 vs Atom debate all over again.
At some point, it might be wise to create a place in the Atom community for creating extensions so that the same process that's being used to hammer out the core specification can be used to work out the kinks in features that don't make it into the core. But with Atom currently at version 0.3, it's probably not time for that yet. Building concrete solutions for tomorrow's problems is probably best left till tomorrow, or at least till the day before, when the problems will be better understood. Today's problems are to build the core, and to decide how to address tomorrow's problems when they arise.
On an unrelated issue that I want to mention, but don't want a separate entry for, if you'd like to help fight illiteracy in Ethiopia, go here.