Veel mensen gebruiken tegenwoordig een RSS-feed om de content van hun site aan te bieden. Zo kan jouw content op andere plaatsen eenvoudig ingelezen en verwerkt worden. Als je een weblog hebt is er zelfs een dikke kans dat die ook een RSS-feed genereert, of je het nu weet of niet.

RSS werkt prima. Niet voor niets schreef ik hier eerder een artikel over. Meer en meer mensen produceren en consumeren RSS-feeds. Atom is een nieuw formaat dat wel eens ‘RSS on steroids’ wordt genoemd. Maar waarom zou je het wiel opnieuw uitvinden als RSS al prima voldoet? In dit artikel ga ik uit de doeken doen wat er zo mooi is aan dit Atom, en ook vooral waarom RSS-fans in Atom geen bedreiging moeten zien, maar juist enthousiast kunnen zijn over de extra mogelijkheden die het biedt.

De problemen van RSS

Zoals gezegd werken deze RSS-feeds in de meeste gevallen prima, dus waarom zou je daar aan tornen? Nou, er zijn een paar problemen met RSS. Er zijn teveel verschillende versies en varianten, waardoor je soms door de bomen het bos niet meer ziet. De ‘beschermheilige’ van RSS, Dave Winer, is een moeilijke man, die soms de zaken niet helemaal objectief bekijkt. Dave heeft onmiskenbaar veel betekend voor de groei van RSS in het bijzonder en syndicatie op het web in het algemeen, maar nu houdt hij die groei tegen. Hij ziet zichzelf als de authoriteit van RSS en wil niet dat zijn belangen geschaad worden.

Maar er zijn ook andere problemen. In sommige gevallen is de RSS-specificatie niet helemaal duidelijk en nauwkeurig. Je kunt dingen doen in een RSS-feed waarvan niemand precies weet hoe je er mee om moet springen. Stel dat je in je RSS feed de volgende passage hebt:

<title>Een verhaal over de <div>-tag.</title>
<description>
  ...
</description>

Je snapt dat deze titel moet worden weergegeven zoals hij is. Het fragment ‘<div>’, moet dus als platte tekst worden afgebeeld, in plaats van als een <div>-tag. Gebeurt dit niet, dan loopt de hele vormgeving in het honderd. Nog een voorbeeldje:

<title>Dit is echt <em>heel</em> complex!</title>

<description>
  ...
</description>

Voor mensen is het duidelijk dat je dit wilt tonen als: "Dit is echt heel complex!". Voor een applicatie die deze feeds moet verwerken is dit onderscheid echter heel moeilijk te maken, en daarom zou het goed zijn als er in de specificatie duidelijk stond hoe er met HTML binnen een <title> omgesprongen moet worden. De RSS-specificatie zegt niet dat HTML mag, maar ook niet dat het niet mag.

Zo zijn er nog meer zaken die niet duidelijk zijn. Hoe moet er worden omgesprongen met relatieve URL’s? Zijn die nu relatief vanaf de plaats waar de feed getoond wordt, of vanaf de oorspronkelijke plaats? En wat dan als de feed lokaal is opgeslagen?

En dat is waarom we Atom nodig hebben! In 2003 is daarom door een groepje Slimme Mensen besloten om aan een nieuw formaat te gaan werken. Dat formaat moet niet alleen deze problemen aanpakken, maar ook gelijk een opvolger worden voor de Blogger-API en Metaweblog-API. Deze API’s maken het mogelijk om tot op zekere hoogte te kunnen communiceren tussen weblogtools. Zo is er bijvoorbeeld de tool w.bloggar waarmee je vanaf je desktop kunt posten op je Blogger- of Movable Type-weblog. Voor deze bestaande API’s gelden deels dezelfde problemen dus besloot men deze ook gelijk aan te pakken. Meer informatie over deze eerste stappen postte Tim Bray op 23 juni 2003 op zijn weblog: I like Pie.

Zo begon men aan de specificatie van Atom. Een formaat dat naast RSS kan bestaan, maar dat ook grote voordelen biedt, namelijk:

• Goede en heldere specificatie;
• ‘Vendor Neutral’, dus onafhankelijk van individuele belangen;
• Gestandaardiseerd, liefst door een erkende, onafhankelijke partij;
• Biedt meer dan alleen syndicatie.

De presentatie van Sam Ruby in oktober geeft een goed beeld van de beweegredenen om aan Atom te beginnen.

Voordelen van Atom

Zoals gezegd biedt Atom voor techneuten en ontwikkelaars veel meer mogelijkheden dan RSS ooit zal kunnen bieden. De Atom-specificatie is onweerlegbaar beter en helderder. In het begin zul je hier als eindgebruiker weinig van merken. De ontwikkelaars die inzien dat Atom een heel groot potentieel heeft beginnen nu met het aanbieden van Atom-feeds, of laten hun applicatie Atom-feeds lezen. Dit om te laten zien dat ze er klaar voor zijn. Er komen dus meer en en meer weblogtools en content management systemen die Atom-feeds genereren naast de RSS-feeds (voor weblogs Blogger, Movable Type en Pivot). Ook steeds meer aggregatoren kunnen met Atom-feeds omspringen. Bijvoorbeeld de desktopapplicatie Feeddemon, de webapplicatie Bloglines.com, en de PHP-feedparser Magpie).

Voor de eindgebruiker maakt het straks geen snars uit of ze nu een Atom- of een RSS-feed lezen. Voor hen is alleen belangrijk dat ze de feeds kunnen lezen en dat het werkt.

Later, als Atom wat volwassener is en de verschillende tools ook de Atom-API (de eerder genoemde opvolger van de Blogger- en MetaWeblog-API) ondersteunen, dan wordt het voor de eindgebruiker pas écht interessant. Via deze API kunnen Atom-enabled applicaties namelijk met elkaar communiceren, in plaats van het éénrichtingsverkeer dat je nu hebt met feeds. Je kunt dan bijvoorbeeld Pivot met Movable Type synchroniseren, zodat beide tools exact dezelfde content bevatten. Je kunt via je desktop-aggregator entries posten op je weblog, of reageren op een ander weblog. Je kunt de archieven van een weblog op veel flexibeler wijze doorzoeken en je kunt backups van al je entries maken in een formaat dat door veel andere tools gelezen zal kunnen worden.

Voor ontwikkelaars

Zoals je al hebt begrepen bestaat Atom eigenlijk uit twee onderdelen: Het Atom Feed Format (dat grotendeels dezelfde functionaliteit biedt als het huidige RSS) en de Atom-API ( vergelijkbaar met de Blogger- of MetaWeblog-API)

Om inzicht te geven in het Feed Format, laat ik hier een heel eenvoudige feed zien, die direct uit de Atom Feed specificatie afkomstig is:

<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#">
 <title>dive into mark</title>

 <link rel="alternate" type="text/html" href=
 "http://diveintomark.org/"/>
 <modified>2003-12-13T18:30:02Z</modified>
 <author>
 <name>Mark Pilgrim</name>
 </author>

  <entry>
  <title>Atom 0.3 snapshot</title>
  <link rel="alternate" type="text/html" href=
  "http://diveintomark.org/2003/12/13/atom03"/>
  <id>tag:diveintomark.org,2003:3.2397</id>
  <issued>2003-12-13T08:29:29-04:00</issued>

  <modified>2003-12-13T18:30:02Z</modified>
 </entry>
</feed>

Zeker als je wel eens naar een RSS-feed (of een ander XML-document) hebt gekeken, zal dit weinig verrassingen opleveren. Een paar dingen die ik wil opmerken:

• Alle data in de feed en entry zijn strikt volgens de door de W3C aangeraden Date and Time Formats. Doordat er een tijdzone-indicator bij staat (in het voorbeeld ‘-04:00’ of ‘Z’) kun je Atom-feeds die je vanuit verschillende locaties bijeen geraapt hebt toch eenduidig sorteren.
• <author> is een zogenaamde ‘person construct’. Hiermee kun je van een persoon zijn of haar naam, URL en e-mail opnemen. Als een feed meerdere auteurs heeft, kun je ook de <author>-tag meerdere malen gebruiken.
• Elke entry is ingesloten door een <entry>-tag, waarbinnen de hele entry beschreven wordt.
• De <id>-tag geeft een unieke identificatie voor deze entry. Deze zal nooit veranderen. Als een entry wordt aangepast, kan een aggregator aan de hand van deze <id> onthouden of een entry gelezen is.

In de praktijk zal de <entry> ook de inhoud van de daadwerkelijke entry of pagina bevatten. Of in ieder geval een deel daarvan. Bij RSS is het gebruikelijk om de platte tekst in de <description> te zetten, en eventueel ook nog de HTML in een <content:encoded>-tag.
Het is dan aan de aggregator om te beslissen wat hiermee gebeurt en hoe ermee wordt omgesprongen. Bij Atom gaat dit anders. Meestal worden de volgende twee tags toegevoegd aan een entry:

<summary type="text/plain">
 Weet je wat een kekke site is? Nu.nl!
</summary>
<content type="text/html" mode="escaped" xml:lang=
"nl" xml:base="http://www.mijnkopthee.nl/archive/...">
 <![CDATA[<p>Weet je wat een kekke site is? <a href=
 "http://www.nu.nl/" rel='external'>Nu.nl</a>!</p>]]>

</content>

Je ziet hier dat de <summary> een attribuut type="text/plain" heeft. De aggregator heeft dus een duidelijke richtlijn hoe deze te interpreteren. Hetzelfde geldt voor de <content>-tag. De <content>-tag is toevallig een HTML-versie van de entry en in het Nederlands, maar dit zou ook Textile of XML kunnen zijn. Als je een meertalige site bijhoudt, kun je de content dupliceren voor elke taal waarin je je site bijhoudt. Bijzonder flexibel, maar toch heel precies.

Hang het aan de grote klok

Als je dan een Atom feed aan je site hebt gehangen, moet je de mensen natuurlijk ook laten weten dat je dit hebt gedaan, anders heb je voor niets al die moeite gedaan om ‘bleeding edge’ te zijn. Dit kan via een knopje zoals je rechts van deze alinea ziet, maar daarnaast wil je in de broncode van de webpagina ook een zogenaamde autodiscovery-tag opnemen. Hiermee kunnen aggregatoren en zoekmachines je feed volautomagisch vinden. Zo’n autodiscovery-tag plaats je in het <head> gedeelte van je site, en ziet er ongeveer zo uit:

<link rel="alternate" type="application/atom+xml" 
title="Atom" href="/atom.xml" />

Makkelijk zat, niet?

Werk in Uitvoering

Zoals je begrijpt is Atom nog in ontwikkeling, en het is daarom ook niet aan te raden om Atom te gebruiken om missie-kritische applicaties aan te sturen. Het is mogelijk (waarschijnlijk zelfs) dat er nog het één en ander zal veranderen aan de specificaties van het Atom Feed formaat en de Atom-API.

Hoe lang het nog duurt voordat Atom klaar is voor het echte werk hangt van een paar factoren af. Soms gedragen de ontwikkelaars zich alsof ze in een soap (nee, niet SOAP) spelen. Sam Ruby (korte bio) en Tim Bray (mede-ontwikkelaar XML) trekken de kar, of zijn in ieder geval voor de media en het grote bedrijfsleven het ‘gezicht’ van Atom. Mark Pilgrim gedraagt zich vaak als een arrogante zak hooi, met steekhoudende argumenten als: “ja, maar jij bent dom.”. Het probleem is alleen dat hij heel vaak ook heel slimme dingen zegt. Verder wordt veel werk verzet door Joe Gregorio en Mark Nottingham. Dave Winer wil niets met Atom te maken hebben. Hij wil geen concurrentie voor ‘zijn’ RSS. Zo nu en dan probeert hij daarom mensen tegen elkaar uit te spelen, waarna er weer een week met modder wordt gegooid in plaats van dat er enige vooruitgang wordt geboekt. Daarna pakt men vaak de draad weer op alsof er niets aan de hand is, dus ik heb goede moed dat we over niet al te lange tijd een goede en bruikbare specificatie van Atom hebben.

Er wordt momenteel in ieder geval een IETF working group opgezet, waardoor Atom een officiële, open standaard kan worden. Naar alle waarschijnlijkheid is er aan het eind van dit jaar een werkbare specificatie, die in het begin van 2005 wordt vastgelegd. Voor meer informatie hierover zie de pagina op de Atom-wiki.

API-nootjes

De Atom-API is nog het meest in ontwikkeling. Regelmatig laaien op de Atom-mailinglijst weer discussies op over welke protocollen er gebruikt moeten worden: Rest-architectuur? SOAP? of toch maar gewoon XML-RPC?. Er zal op dit gebied dus nog wel het één en ander veranderen voor de API bruikbaar wordt. Daarom heb ik het wat betreft de API in dit artikel kort gehouden. Ik wil wel wijzen op een aantal bronnen waar je meer informatie kunt vinden.

Op XML.com staan twee artikelen van de hand van Mark Pilgrim: Eén met een inleiding over de API, waarin ook wordt uitgelegd wat er schort aan de huidige weblog-API’s. Daarnaast een artikel over het voorgestelde authenticatieprotocol dat Atom zal gaan gebruiken. Geen beveiligde verbinding en toch afgeschermd tegen nieuwsgierige aagjes!

Als je wilt weten hoe de Atom-API nou precies in elkaar zit, dan vind je de voorlopig officiële specificatie van de API op Joe Gregorio’s Atom-projectpagina.

Voor meer technische info over de Atom-API verwijs ik je naar de huidige specificatie: The Atom Syndication Format 0.3 (PRE-DRAFT)

RSS is niet stom

Ik ben dus erg enthousiast over Atom, en ik denk dat over pakweg een jaar heel veel weblogtools en content management systemen ‘Atom-enabled’ zullen zijn. Zodra de Atom-API specifiatie iets volwassener is, ga ik deze ook zeker inbouwen in Pivot. Hiermee wil ik helemaal niet zeggen dat ik RSS nu ineens stom vind. Als het je te doen is om makkelijk veel informatie tot je te nemen, dan voldoet RSS daar prima in. Atom zal dus ook niet direct RSS vervangen, maar de twee formaten kunnen prima naast elkaar bestaan.

Als straks de Atom API ook daadwerkelijk klaar is voor gebruik en we Atom gaan gebruiken voor tweewegscommunicatie, dan zal pas echt blijken wat de toegevoegde waarde van Atom is. Ik kan alvast niet wachten, en tot die tijd hou ik Atom Enabled goed in de gaten!

• Home
• Artikelen
• Colofon