subbu allamaraju recently raised the question of Atom as a General-Purpose Format, and showed one example (Google Code Search Data API) that looked like a not-so-great way of using Atom. in my comment on his blog, i agreed to his observation that this did not look all that great as far as Atom goes, but i also argued that it might still make sense to use Atom for such a scenario.
comparing Atom with HTML (not as formats, but as methods for information dissemination) can teach us a lot, in particular when looking at possible future developments for Atom. the Atom Landscape already shows some similarities to HTML, thanks to Atom's extension semantics. there are microformats (licenses and paging, for example), there is a lot of custom code only picked up by custom clients (such as subbu's Code Search Data API example), and some of the Atom on the Web is so badly crippled that it is utterly useless for plain Atom clients. that's exactly like the good old best viewed in Internet Explorer
web pages.
however, while this might not be what we want to see, it may very well be what we need to see to make Atom as exciting as i think it will be. the web is what it is exactly because HTML is so bad. HTML is bad on many different levels and not good at anything in particular. but it's sufficient as a container for an astonishing number of things, and it is simple enough to be learned and used by many. people still use PDF when they care about display fidelity and Flash when they care about multimedia features, but all of these formats are nothing compared to HTML.
REST still is on its way up and i am concerned about the fact that it has been officially downgraded into a buzzword and will suffer the hype cycle backlash at some point in time. but regardless of that, REST is what makes the web tick, and for many people, REST is still hard to grasp (our WWW2009 From SOA to REST
tutorial last week was great, but also showed us that there is quite some way to go to spread the message). having best practices and design patterns and frameworks and tools will help a lot, and i expect all of these to appear around Atom.
and we will see all the things that are inevitable when something gets picked up by many. we'll see under-specified extensions (such as GeoRSS), overlapping formats (such as Apple's Podcasts and Yahoo's Media RSS), toolkits (for example supporting feed paging and archiving), and all the other things (some of them invasive and/or malicious) we have seen in HTML. and as inconvenient as that may be from time to time, it also and most importantly is the sure sign of a healthy and active ecosystem.
so what does all of that mean for Atom-oriented developers? similar things as for HTML-oriented web designers, plus some extra care that's required because your goal is to be understood by machines, not by humans. always validate what you're producing, test with other than your preferred clients (such as a plain Atom feed reader), try to reuse established standards in the Atom Landscape or promising candidates for new formats, and most importantly: build your system in a way so that you can change and adapt. if new standards or formats emerge, you should be able to support them, because you have implemented a clear and clean separation between your model (whatever it may be) and the representation of it (Atom plus some extensions).
I couldn't agree more. I'll be curious to see the reaction and what sort of conversation this generates.
Posted by: Peter Keane | Friday, May 01, 2009 at 12:07