RSS - Nachrichtendienste für Jedermann

Transkript

1 RSS - Nachrichtendienste für Jedermann Seminararbeit im Seminar Neue Technologien in Internet und WWW Wintersemester 2003/04 Universität Jena vorgelegt von Christoph Langguth chr lang@informatik.uni-jena.de Januar 2004

2 Abstract RSS (Rich Site Summary) wurde ursprünglich als Datenaustauschformat entwickelt, das es ermöglicht, auf einfache Weise Teile einer Webseite (z.b. Schlagzeilen) in andere Webseiten einzubinden. Durch Weiterentwicklungen wurden die Anwendungsmöglichkeiten ausgedehnt und das Format flexibler gestaltet, so daß RSS heute als leichtgewichtiges Format zur Verbreitung verschiedenster Informationen bei einer immer weiter wachsenden Nutzergemeinde Verwendung findet angefangen bei Nachrichtenschlagzeilen, über Zusammenfassungen von Weblog-Einträgen und Verfolgung der Änderungen in diesen, bis hin zur Überwachung der Funktionstüchtigkeit von Servern. Die vorliegende Arbeit beschreibt die Ursprünge und die Entwicklung von RSS. Dabei werden die Spezifikationen der verschiedenen Versionen von RSS dargestellt und diskutiert. Anschließend folgt ein Überblick über die Verwendung von RSS aus Nutzersicht und die verwendeten Mechanismen, die Publish & Subscribe d.h. das Abonnieren von Informationen ermöglichen.

3 Inhaltsverzeichnis 1 Einleitung 1 2 Allgemeines zu RSS RSS: ein XML-basiertes Datenformat Übertragung von RSS-Dateien Wichtige Begriffe Entwicklung von RSS RSS Struktur von RSS RSS Struktur von RSS Neue Elemente in RSS RSS Struktur von RSS Neue Elemente in RSS Weitere Änderungen in RSS RSS Struktur von RSS Module in RSS RSS Struktur von RSS Änderungen in RSS Clients für RSS Aggregatoren Desktop-Clients Publish & Subscribe Publish & Subscribe mit RSS 0.92 und Publish & Subscribe mit RSS Bemerkungen zu Publish & Subscribe

4 10 Zusammenfassung 27 A Glossar 28 B Wichtige Internetadressen 29 C Abkürzungen und Akronyme 29 Literaturverzeichnis 30 Index 31

5 1 Einleitung Das Internet hat sich zu einer der wichtigsten Informationsquellen entwickelt nahezu zu jedem beliebigen Thema gibt es jetzt schon eine Fülle von Informationen im WWW. Gleichzeitig wächst das Netz der Netze unaufhaltsam, täglich entstehen mehrere Millionen neue Webseiten. Es ist unmöglich, zu einem gesuchten Thema tatsächlich alle vorhandenen Informationen zu finden, geschweige denn sie alle zu verarbeiten. Doch selbst wenn man viele relevante Informationsquellen schon gefunden hat, ist es quasi unmöglich, diese alle im Auge zu behalten, speziell wenn es sich um sich schnell ändernde Daten, wie z.b. Nachrichten, handelt: zu viel Zeit würde mit dem Aufrufen der verschiedenen Seiten und der Suche nach Änderungen (also z.b. neuen Nachrichten) vergeudet, zu wenig Zeit bliebe, um sich mit dem eigentlichen Inhalt zu befassen. Dieses Problem wurde 1999 zum ersten Mal von Netscape adressiert: indem die Firma auf ihrem Kundenportal My Netscape Network personalisierbare Seiten einführte, die vom Nutzer angegebene Inhalte von anderen Webseiten anzeigen konnten, gab sie dem Nutzer die Möglichkeit, an einer zentralen Anlaufstelle viele Informationen verschiedener Anbieter zusammenzufassen. Natürlich mußten sich die Fremdanbieter an ein bestimmtes, von Netscape vorgegebenes Datenformat halten, um die Einbindung ihrer angebotenen Informationen in das Portal zu ermöglichen. Dieses Format wurde von Netscape RSS (Rich Site Summary) genannt und trug in seiner urprünglichen Form die Versionsnummer 0.9. Kapitel 2 gibt zunächst einen Überblick über RSS und erläutert die zugrundeliegenden Protokolle und Datenformate sowie die geschichtliche Entwicklung von RSS. Die Kapitel 3 bis 7 beschäftigen sich dann genauer mit den verschiedenen veröffentlichten Versionsspezifikationen. In Kapitel 8 wird näher auf die Benutzung von RSS als Anwender bzw. Programmierer eingegangen, bevor in Kapitel 9 auf die Schwierigkeiten eingegangen wird, die entstehen, wenn bestmögliche Aktualität bei gleichzeitig geringem Netzverkehr gefordert wird. Kapitel 10 schließlich gibt eine kurze Zusammenfassung und zeigt aktuelle Entwicklungen auf. 2 Allgemeines zu RSS In diesem Kapitel werden einige allgemeine Eigenschaften des Datenformats beschrieben, die für alle Versionen von RSS gelten. Es wird auf das Datenformat selbst, auf dessen Ursprünge und auf die Übertragung der Daten eingegangen. Desweiteren werden die unterschiedlichen Philosophien der Entwickler von RSS aufgezeigt, die zu Inkompatibilitäten zwischen den verschiedenen Versionen und zu verschiedenen Auslegungen des Akronyms RSS geführt haben. 1

6 2.1 RSS: ein XML-basiertes Datenformat Die ursprüngliche Version von RSS wurde 1999 entwickelt, mit dem Ziel, strukturierte Daten zwischen verschiedenen Computern die unter Umständen auf verschiedenen Betriebssystemen liefen austauschen zu können. Zu diesem Zeitpunkt existierte bereits ein Datenformat, mit dem sich äußerst detaillierte Informationen über Dokumente darstellen lassen: RDF (Resource Description Framework). Das hehre Ziel der RDF-Entwickler ist das Semantic Web, in dem das komplette Netz semantisch erfaßt wäre, so daß tatsächlich der Sinn eines jeden verfügbaren Dokuments aus dessen Beschreibung abzulesen wäre. RDF selbst ging 1997 aus dem seit 1995 von Ramanathan V. Guha entwickelten MCF (Meta Content Framework) hervor; zu diesem Zeitpunkt wurde MCF als eines der ersten Datenformate überhaupt als XML-Anwendung implementiert (XML: Extensible Markup Language). XML ist eine Art Meta-Beschreibungssprache; es lassen sich prinzipiell fast beliebig komplexe auf XML basierende Datenformate definieren. Im folgenden werden einige Punkte aufgezählt, die XML heute so beliebt machen (und die auch damals wohl den Ausschlag dafür gaben, RDF als XML-Applikation zu implementieren): XML definiert keine starre Menge von verwendbaren Elementen, vielmehr kann diese Menge beliebig definiert werden mit XML lassen sich auch sehr komplexe Datenstrukturen darstellen, da ein XML-Dokument einen Baum darstellt XML ist plattformunabhängig, d.h. XML-Dokumente können auf den verschiedensten Betriebssystemen verarbeitet werden um XML verarbeiten zu können, benötigt man im Prinzip nur einen XML- Parser 1 und Informationen über den logischen Aufbau des zu verarbeitenden Dokuments XML-Dokumente sind sowohl für Maschinen als auch (relativ problemlos) für Menschen lesbar Dadurch, daß die erste Version von RSS an RDF angelehnt war, wurde das Format also quasi automatisch als XML-Anwendung spezifiziert. Damit einher gehen für Entwickler, die mit RSS arbeiten wollen, alle Annehmlichkeiten, die mit XML verbunden sind: man kann Programme, die RSS erzeugen (Server) bzw. verarbeiten (Clients) praktisch in jeder beliebigen Programmmiersprache ohne großen Aufwand erstellen, da mittlerweile für alle Sprachen XML-Werkzeuge existieren. Natürlich genügt es nicht, RSS nur verarbeiten zu können da es sich hier per definitionem um Daten handelt, die zwischen verschiedenen Maschinen über ein 1 ein XML-Parser ist eine Software, die die Struktur eines XML-Dokuments verarbeiten kann. Solche Software gibt es mittlerweile für alle wichtigen Programmiersprachen und Betriebssysteme. 2

7 Netzwerk fließen, müssen die Programme auch das Versenden bzw. Empfangen der Daten bewerkstelligen. Auch hier haben sich die Entwickler entschieden, auf einfach zu verwendende (und bewährte) Übertragungswege zurückzugreifen. 2.2 Übertragung von RSS-Dateien Der ursprünglich einzige Einsatzzweck von RSS war es, (Teile von) Informationen einer Webseite anderen Seiten zur Verfügung zu stellen. Da alle Seiten im WWW von Webservern zur Verfügung gestellt werden und diese beliebige Daten mittels HTTP an die Clients senden können, bot es sich an, auch für das Bereitstellen von RSS-Dokumenten auf die bewährten Techniken zurückzugreifen zumal ja XML-Dokumente auch nur Textdokumente sind. RSS-Dateien werden also ganz normal vom Anbieter auf einem Webserver bereitgestellt. Um dem Empfänger mitzuteilen, um welchen Dokumenttyp es sich bei dem zurückgelieferten Dokument handelt, senden Webserver einen sogenannten Content-Type im Header 2 mit. Der empfohlene Content-Type für RSS ist application/xml+rdf. Es wird außerdem empfohlen, als Dateiendung für RSS- Dateien.xml oder.rdf zu verwenden. Diese Vorgaben sind allerdings nur als Empfehlung zu werten, da keines der aktuellen Client-Programme ein Problem mit einem anderen Content-Type (etwa text/xml) oder Endungen (wie.pl oder.php, welche auf serverseitige Skripte hinweisen) haben dürfte. 2.3 Wichtige Begriffe Der vom Anbieter im RSS-Format bereitgestellte Inhalt wird als (RSS-)Feed bezeichnet. Zu unterschiedlichen Zeitpunkten können unter der Adresse, unter der der Feed zu finden ist, durchaus verschiedene Dokumente bereitgestellt werden (da sich ja der Inhalt der Dokumente ändern kann), trotzdem werden die Begriffe RSS-Feed und RSS-Dokument weitgehend synonym verwendet, da aus dem Kontext meist ersichtlich ist, ob es sich um das Konzept oder um eine konkrete Ausprägung handelt. Ein RSS-Feed enthält genau einen Channel analog zum Fernsehen, in dem auf jeder Frequenz auch nur ein Sender ausgestrahlt wird. Ein Item stellt eine logische Einheit dar, die konzeptuell zum Channel gehört 3. Jedes Item enthält Informationen zu einer Ressource (bei Nachrichten-Feeds etwa zu einem bestimmten Artikel, bei Weblogs 4 zu einem Eintrag etc.). Eine Ressource ist ein abstraktes Konzept für Irgendetwas, das eindeutig identifiziert werden kann. Die Identifizierung erfolgt dabei über URI s (URI: Uniform Resource Identifier). In den meisten Fällen ist ein URI ein URL (Uniform 2 Ein Header (deutsch etwa: Nachrichtenkopf) enthält Daten, die vom Server vor den eigentlichen Nutzdaten gesendet werden und die Informationen über die Nutzdaten enthalten, wie etwa die Dokumentlänge, das Verfallsdatum oder eben den Dokumenttyp. 3 Diese konzeptuelle Zugehörigkeit ist nicht in allen Versionen aus der Struktur des RSS- Dokuments ersichtlich, insbesondere nicht in der Version 0.9 (siehe Kapitel 3). 4 Ein Weblog ist eine Art Internet-Tagebuch. 3

8 Resource Locator), d.h. eine Internet-Adresse, unter der das entsprechende Objekt (Dokument, Bild, Webseite) gefunden werden kann Entwicklung von RSS Obwohl RSS ein noch relativ junges Dokumentformat ist, hat es eine recht bewegte Geschichte hinter sich: im Laufe der Entwicklung von RSS entstanden mehrere zueinander inkompatible Versionen, und auch die Bedeutung der Abkürzung RSS wurde mehrfach umdefiniert. Auslöser für diese Entwicklung waren Meinungsverschiedenheiten der Entwickler: auf der einen Seite stand Dave Winer, der einen möglichst einfachen Standard präferierte, auf der anderen Seite die Entwickler der rss-dev-mailingliste, die die Möglichkeiten von RDF ausschöpfen wollten. Im folgenden werden die verschiedenen Standards in chronologischer Reihenfolge ihrer Veröffentlichung dargestellt: RSS 0.9 (1999): die erste Version von RSS, entwickelt von Netscape. Diese Version war ursprünglich komplett RDF-basiert; da einige Entwickler jedoch glaubten, daß das komplette RDF-Datenmodell für den Endbenutzer zu kompliziert wäre, wurden Teile davon gestrichen mit dem Resultat, daß die dadurch entstandene Kompromißlösung weder so einfach war, wie sie es hätte sein können, noch gültiges RDF. Diese Version wurde ursprünglich Rich Site Summary genannt. RSS 0.91 (Juni 2000): Weiterentwicklung von Userland (Dave Winer). In Version 0.91 wurde die RDF-Funktionalität komplett entfernt. Dadurch wurde der Aufbau der Datei intern logischer gestaltet und Inkompatibilitäten zu richtigem RDF vermieden. Allerdings waren Dateien dieser Version nicht mehr mit der Version 0.9 abwärtskompatibel. In dieser Version wurde die Abkürzung RSS umgedeutet als Really Simple Syndication. RSS 1.0 (Dezember 2000): Entwicklung der rss-dev-mailingliste. Diese Version unterstützte Module, XML-Namespaces und implementierte ein komplettes RDF-Datenmodell. Damit ist diese Version näher an der ursprünglichen Version 0.9 anzusiedeln, behob aber deren Fehler, indem das Datenformat tatsächlich RDF-konform war. Die Version 1.0 war somit auch inkompatibel zu Version 0.91, RSS wurde hier als Abkürzung von RDF Site Summary verstanden. RSS 0.92 (Dezember 2000): Weiterentwicklung von Version Version 0.91 fügte ihrer Vorgängerversion 0.91 zahlreiche Elemente hinzu und hob einige von deren Beschränkungen auf. Die Spezifikation sah jedoch (nach wie vor) weder ein RDF-Datenmodell noch die in Version 1.0 verwendeten Module oder Namespaces vor. Sie wurde gewissermaßen als RDF-freie Alternative zu RSS 1.0 angeboten. 5 Ein URI muß nicht unbedingt ein gültiger URL sein, es kann auch z.b. eine Mail-Adresse (als Konzept für eine Person) oder eine beliebige Zeichenkette sein, die das Objekt eineindeutig identifiziert. 4

9 Version Erscheinungsdatum RDF-basiert? RDF-kompatibel? Module? ja nein nein /2000 nein nein nein /2000 ja ja ja /2000 nein nein nein /2002 nein nein ja Tabelle 1: Überblick über die verschiedenen RSS-Versionen RSS 0.93 (Mitte 2002): auf RSS 0.92 basierende Weiterentwicklung. Diese von Dave Winer entwickelte Version hat nie offiziell das Licht der Welt erblickt, sämtliche in ihr enthaltenen Änderungen gegenüber der Vorgängerversion wurden in Version 0.94 übernommen. RSS 0.94/2.0 (August 2002): Weiterentwicklung von RSS In dieser auf RSS 0.92 basierenden Version wurde die 0.92-Spezifikation erneut um neue Elemente erweitert; gleichzeitig wurde die Unterstützung von XML-Namespace und Modulen (die allerdings inkompatibel zu den in Version 1.0 verwendeten Modulen sind) eingeführt. Die ursprüngliche Versionsnummer 0.94 wurde bald in 2.0 geändert und die Entwicklung als frozen (eingefroren) deklariert auf diesem Entwicklungszweig von RSS sind also keine weiteren Neuerungen zu erwarten. RSS 2.0 ist wie seine Vorgängerversionen (0.9x) nicht RDF-kompatibel. Diese doch relativ konfuse Entwicklungsgeschichte von RSS wird in zwei recht amüsanten Aussagen von an der Entwicklung beteiligten scherzhaft aufgegriffen. In der Spezifikation von RSS 0.91 findet sich folgender Satz von Dave Winer: There is no consensus on what RSS stands for, so it s not an acronym, it s a name. Later versions of this spec may say it s an acronym, and hopefully this won t break too many applications. Der Streit um das richtige Format fand seine Krönung in einem Beitrag in der rss-dev-mailingliste, in dem vorgeschlagen wurde, die RSS 4.0-Spezifikation durch Ausdruckstanz zu definieren 6 [Ham03]. Tabelle 1 zeigt eine Zusammenfassung der verschiedenen Versionen von RSS. 3 RSS 0.9 Die erste Spezifikation von RSS, veröffentlicht im Jahre 1999 von der Firma Netscape, hatte einen einzigen Verwendungszweck: Teile des Inhalts einer Webseite in einem RSS-Feed zur Verfügung zu stellen, so daß diese auf einer anderen Webseite namentlich: auf Netscapes Portalseite My Netscape Network, 6 Eventuelle Informationen über RSS 3.0 und 4.0 sind also als Scherze aufzufassen. 5

10 damals zu erreichen unter angezeigt werden konnten. Jeder Nutzer, der bei diesem Portal angemeldet war, konnte die für ihn angezeigten Seiten personalisieren, indem er (mehrere) Channel unterschiedlicher Anbieter abonnierte. Netscape zeigte die Informationen aus den gewählten Feeds dann auf der Benutzerseite in einem einheitlichen Design an, indem die Inhalte der RSS-Feeds in HTML konvertiert und in die Netscape-Seite eingebunden wurden. Der Grund für diese Entwicklung war, daß sich Netscape dadurch längere Verweilzeiten auf seinen Seiten erhoffte. Aber nicht nur Netscape konnte von einem Einbinden von Fremdinhalten auf ihren Webseiten profitieren, vielmehr bot diese Strategie Vorteile für alle Beteiligten: Endanwender: profitiert von der Verfügbarkeit verschiedenster Informationen aus unterschiedlichen Quellen an einem einzigen Anlaufpunkt. Netscape: profitiert unmittelbar dadurch, daß ihre Seite im Wert für den Benutzer durch die zusätzlichen Informationen steigt; daraus folgt eine längere Verweildauer auf der Seite und somit höhere Einnahmen durch Werbung von Dritten. Feed-Anbieter: profitiert von der größeren Verbreitung seiner Informationen und kann dadurch möglicherweise mehr Besucher auf seiner eigenen Webpräsenz verzeichnen. Um einen Besucher darauf hinzuweisen, daß seine Webseite einen Feed bereitstellte, der im Netscape-Portal nutzbar war, konnte der Drittanbieter auf seinen Seiten eine kleine Grafik einbinden, die es dem Nutzer ermöglichte, bei einem Klick darauf den Channel automatisch zu abonnieren. Abbildung 1 zeigt diese Grafik und beispielhaft das Aussehen eines Feeds im Browser des Anwenders (Quelle: [RSS09]). Abbildung 1: Add to My Netscape -Grafik, Beispiel-Feed 6

11 rdf:rdf channel textinput image item description description url name Abbildung 2: Struktur von RSS Struktur von RSS 0.9 Ein Dokument im RSS-0.9-Format ist relativ einfach aufgebaut. Abb. 2 zeigt, wie ein solches Dokument strukturiert ist. Das Wurzelelement ist, angelehnt an die RDF-Spezifikation, ein rdf:rdf-element 7. Das Wurzelelement rdf:rdf kann vier verschiedene Elementtypen beinhalten: channel, image, textinput und item. channel (obligatorisch, 1) In jedem RSS-0.9-Dokument muß genau ein Channel definiert werden dies geschieht über das Element channel. Weitere Eigenschaften des Channels werden in dessen Kindelementen festgelegt: (obligatorisch, 1) Dieses Element definiert den Titel bzw. Namen des Channels. Der Titel darf aus maximal 40 Zeichen bestehen. Dieser Titel wird dem Anwender als Überschrift des Channels angezeigt. description (obligatorisch, 1) Das description-element sollte eine etwas ausführlichere Beschreibung des Channels enthalten. Diese Beschreibung darf maximal 500 Zeichen lang sein. (obligatorisch, 1) In diesem Element findet sich ein URL, der auf die Webseite des Feed- Anbieters verweist. Die maximale Länge des URL ist 500 Zeichen. image (optional, höchstens 1) Dieses Element weist darauf hin, daß zu dem Feed ein Bild bereitgestellt wurde, welches dem Anwender (z.b. neben dem Channel-Titel oder statt- 7 Damit diese Benennung sinnvoll ist, muß der Namespace rdf in der Datei mit Verweis auf die RDF-DTD eingebunden werden (siehe dazu Abb. 3). 7

12 dessen) angezeigt werden kann. Das image-element hat folgende Kindelemente: (obligatorisch, 1) Dieses Element wurde in der Spezifikation verwendet, um das alt- Attribut des img-tags in HTML festzulegen (also den Text, den der Anwender zu sehen bekam, wenn sein Browser keine Bilder anzeigte). Die maximale Länge des Inhalts wurde auf 40 Zeichen festgelegt. url (obligatorisch, 1) URL zum darzustellenden Bild. Das Bild muß 88x31 Pixel groß sein (Breite x Höhe). Die maximale Länge des URL ist 500 Zeichen. (obligatorisch, 1) Auch in diesem Feld muß ein URL stehen, der auf die Webseite des Feed-Anbieters verweist. Der URL darf höchstens 500 Zeichen lang sein. textinput (optional, höchstens 1) Der Sinn des textinput-element ist nicht völlig klar definiert, es wurden allenfalls Aussagen gemacht, wofür es verwendet werden kann. Wenn ein solches Element im Feed existiert, dann soll dem Nutzer ein Eingabefeld zur Verfügung gestellt werden, in das er Text eingeben und diesen Text dann an einen URL senden kann. Sinnvolle Möglichkeiten für den Einsatz dieses Elements würden zum Beispiel Suchfunktionen auf der Seite des Feed-Anbieters oder Feedback zu diesem darstellen. Für dieses Element sind folgende Kindelemente definiert: (obligatorisch, 1) Der Titel des textinput-elements, z.b. Feedback senden. Dieser wurde vermutlich als Text für den Button, der zum Absenden des Formulars diente, verwendet und durfte maximal 40 Zeichen lang sein. description (obligatorisch, 1) Die Beschreibung des Textfeldes, das zur Eingabe dient (maximal 100 Zeichen). (obligatorisch, 1) Dieses Element enthält den URL, an den die vom Benutzer eingegebenen Daten gesendet werden. Von Netscape wurde nur die GET- Methode zur Übergabe von Daten unterstützt 8. Der URL darf maximal 500 Zeichen lang sein. name (obligatorisch, 1) Hier wird der Name des Elements definiert, unter dem die Daten vom Nutzer an den im -Element angegebenen URL gesendet werden. Der Name darf höchstens 500 Zeichen lang sein. 8 Es gibt zwei Methoden, um vom Nutzer eingegebene Daten an einen Webserver zu senden: GET und POST. Einzelheiten dazu finden sich in der HTTP-Spezifikation. 8

13 <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xmlns=" <channel> <>Mozilla Dot Org</> <> <description>the Mozilla Organization web site</description> </channel> <image> <>Mozilla</> <url> <> </image> <item> <>New Status Updates</> <> </item> <item> <>Bugzilla Reorganized</> <> </item> <item> <>Mozilla Party, 2.0!</> <> </item> <item> <>Unix Platform Parity</> <> </item> <item> <>NPL 1.0M published</> <> </item> </rdf:rdf> Abbildung 3: Beispieldokument RSS 0.9 item (obligatorisch, 1 bis 15) Ein Channel muß mindestens ein Item enthalten, maximal sind 15 Items erlaubt. Jedes Item stellt dabei eine bestimmte Information im allgemeinen eine Schlagzeile dar und hat zwei Kindelemente: (obligatorisch, 1) Der Titel (die Überschrift) des Items. Dieser Text wird dem Anwender angezeigt und darf bis zu 100 Zeichen lang sein. (obligatorisch, 1) Hier wird der URL eingetragen, auf den das Item vert wird und zu dem der Nutzer gelangt, wenn er das Item auswählt. Der URL darf maximal 500 Zeichen enthalten. Abb. 3 zeigt ein einfaches Beispiel für RSS 0.9 (Quelle: [RSS09]). Diese erste Version von RSS war auf ihren ganz speziellen Einsatzzweck maßgeschneidert. Dadurch ergab sich ein sehr einfaches Dateiformat, welches jedoch 9

14 einige Beschränkungen (z.b. hinsichtlich der Länge und Anzahl der Elemente) aufwies. Da sich die Möglichkeiten von RSS auch wesentlich vielseitiger nutzen lassen, z.b. auch mit eigenen Programmen, die Nachrichten-Feeds verarbeiten können, erwiesen sich diese Beschränkungen bald als ärgerlich. Die Nachfolgerversion, RSS 0.91, sollte RSS in vieler Hinsicht verbessern. 4 RSS 0.91 RSS 0.91, in das Ideen von RSS 0.9 und aus dem von Dave Winer entwickelten Format namens ScriptingNews 2.0b1 einflossen, wurde der Öffentlichkeit im Juni 2000 präsentiert. Es sollte einerseits einige Beschränkungen von RSS 0.9 aufheben und dieses andererseits um neue Funktionalitäten erweitern. Insbesondere werden mehrere neue Elemente definiert, die Informationen über den Feed enthalten, sogenannte Metadaten. RSS 0.91 verzichtet komplett auf ein RDF-Datenmodell. Diese Entscheidung fiel deshalb, weil RSS 0.9 zwar auf RDF basierte, die Dateien jedoch keine korrekten RDF-Dateien waren 9. Der Verzicht auf RDF brachte eine Umstrukturierung des Aufbaus der Datei mit sich dadurch war das neue Format nicht abwärtskompatibel Struktur von RSS 0.91 Abbildung 4 zeigt den Aufbau eines RSS-0.91-Dokuments. Änderungen bzw. Neuerungen gegenüber RSS 0.9 sind farblich markiert. Abbildung 5 zeigt ein Beispieldokument (Quelle: [Ham03], leicht modifiziert). In Version 0.91 wurde das Wurzelelement rdf:rdf durch das Element rss (welches das Attribut version mit dem Inhalt 0.91 haben muß) ersetzt, und alle anderen Elemente wurden zu Kindelementen von channel dadurch spiegelt sich in der Struktur des Dokuments besser wider, daß die Items logisch zum Channel gehören. Weiterhin wurde der in Version 0.9 noch vorhandene (Standard-) XML-Namespace für RSS entfernt. 4.2 Neue Elemente in RSS 0.91 In der Version 0.91 wurden RSS mehrere neue Elemente hinzugefügt. channel: dem channel-element wurden folgende neuen Elemente hinzugefügt, die Metadaten über den Channel enthalten: language (obligatorisch, 1): die Sprache, in der die Items des Feeds verfaßt sind, z.b. en oder de. 9 Es wurde argumentiert, daß lieber gar kein RDF-Datenmodell verwendet werden sollte als ein inkorrektes. 10 Für die Implementierung von RSS-Anwendungen stellt diese Inkompatibilität jedoch kein großes Problem dar. 10

15 rss version=0.91 channel textinput description description language name copyright rating docs webmaster pubdate managingeditor lastbuilddate image url width height description skipdays day skiphours hour item description Abbildung 4: Struktur von RSS 0.91 copyright (optional, höchstens 1): ein Copyright-Hinweis zum Inhalt des Channels (max. 100 Zeichen). managingeditor (optional, höchstens 1): die -Adresse des Verantwortlichen für den Inhalt des Channels (höchstens 100 Zeichen). Das empfohlene Format ist (Vorname Nachname). webmaster (optional, höchstens 1): die -Adresse des für den Feed verantwortlichen Webmasters (maximal 100 Zeichen). rating (optional, höchstens 1): die PICS-Bewertung des Feeds. pubdate (optional, höchstens 1): das Veröffentlichungsdatum des Inhalts des Channels. Das Datum muß in dem im RFC 822 definierten Format vorliegen. [... ] the New York Times publishes on a daily basis, the publication date flips once every 24 hours. That s when the pubdate of the channel changes. [RSS091] lastbuilddate (optional, höchstens 1): das Datum, an dem sich der Inhalt des Channels zum letzten Mal geändert hat, im im RFC 822 definierten Format. docs (optional, höchstens 1): URL zu einer Seite, die das Format der Datei erklärt (maximal 500 Zeichen). Dort sollte sich die Spezifikation von RSS 0.91 befinden. skipdays (optional, max. 7) und skiphours (optional, max. 24): diese Elemente sollen den Zugriff auf den Feed reglementieren, d.h. Zeiträume anzugeben, in denen der Feed nicht abgerufen werden 11

16 <?xml version="1.0" encoding="iso "?> <rss version="0.91"> <channel> <>RSS0.91 Example</> <> <description>this is an example RSS0.91 feed</description> <language>en-gb</language> <copyright>copyright 2002, Oreilly and Associates.</copyright> <rating></rating> <pubdate>03 Apr GMT</pubDate> <lastbuilddate>03 Apr GMT</lastBuildDate> <docs> <skipdays> <day>monday</day> </skipdays> <skiphours> <hour>20</hour> </skiphours> <image> <>RSS0.91 Example</> <url> <> <width>88</width> <height>31</height> <description>computer Books, Conferences, Online Publishing</description> </image> <textinput> <>Search</> <description>search our website</description> <name>searchstring</name> <> </textinput> <item> <>The First Item</> <> <description>this is the first item.</description> </item> <item> <>The Second Item</> <> <description>this is the second item.</description> </item> <item> <>The Third Item</> <> <description>this is the third item.</description> </item> </channel> </rss> Abbildung 5: Beispieldokument RSS

17 soll. Das skipdays-element kann bis zu sieben day-kindelemente enthalten, die einen der Werte (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) haben. Das skiphours- Element kann bis zu 24 hour-kindelemente enthalten, die jeweils einen Wert zwischen 1 und 24 enthalten und eine Uhrzeit (Stunde) repräsentieren. Ein Client darf zu einem Zeitraum, der einem der Wochentage bzw. Stundenzeiträume (in Greenwich Mean Time (GMT)) entspricht, den Feed nicht abrufen die allermeisten Clients ignorieren diese Angaben allerdings. image: dieses Element erhielt drei neue Kindelemente, die RSS flexibler für neue Anwendungen machen. width (optional, maximal 1) und height (optional, maximal 1): diese Elemente enthalten die Breite bzw. Höhe des zum Channel gehörenden Bilds. Damit wurde die Beschränkung auf ein einziges Bildformat 88 x 31 Pixel in RSS 0.9 aufgehoben. Allerdings sind auch hier noch Beschränkungen vorhanden: width darf maximal den Wert 144 annehmen, height darf höchstens 400 betragen. Sind eines oder beide Elemente nicht vorhanden, so wird als Standardwert 88 bzw. 31 verwendet. description (optional, maximal 1): enthält eine Zeichenkette, die bei der Umwandlung in HTML für das -Attribut der img-tags verwendet werden kann. item: eine der interessantesten Neuerungen in RSS 0.91 war das Hinzufügen des description-elements als (optionales) Kindelement zum item-element. Das neue Element kann bis zu 500 Zeichen enthalten, die eine kurze Beschreibung der verten Ressource darstellen bei Nachrichten-Feeds etwa eine kurze Zusammenfassung des Artikels, zusätzlich zur im -Element enthaltenen Überschrift. RSS 0.91 ist nach wie vor die beliebteste Version von RSS, ca. 55% der 2003 angebotenen Feeds benutzten dieses Format [Ham03]. Dies ist wohl darauf zurückzuführen, daß viele der von den Nachfolgerversionen angebotenen Möglichkeiten von den Anbietern nicht benötigt werden, da mit den angebotenen Funktionalitäten genügend Flexibilität gegeben ist, oder daß die Anwender vor deren erhöhter Komplexität zurückschrecken. 5 RSS 0.92 Dieses Kapitel beschreibt Version 0.92 von RSS, die zwar chronologisch zwei Wochen nach der Version 1.0 erschien, aber eine konsequente Weiterentwicklung von RSS 0.91 ist. Die Version ist als Weiterentwicklung von RSS 0.91, aber auch als RDF-freier Gegenvorschlag zum vollständig RDF-basierten RSS 1.0 (siehe Kapitel 6) zu verstehen. 13

18 rss version=0.92 channel description language copyright rating docs webmaster pubdate managinged. lastbuildd. textinput description name cloud domain port path protocol registerprocedure image url width height description skipdays day skiphours hour item description source url category domain enclosure url length type Abbildung 6: Struktur von RSS 0.92 RSS 0.92 zeichnet sich gegenüber Version 0.91 weniger durch die (relativ wenigen) neu hinzugekommenen Elemente aus, sondern vielmehr dadurch, daß viele Beschränkungen der Vorgängerversion aufgehoben wurden. 5.1 Struktur von RSS 0.92 Abbildung 6 zeigt den Aufbau eines RSS-0.92-Dokuments. Änderungen bzw. Neuerungen gegenüber RSS 0.91 sind farblich markiert. Abbildung 7 zeigt ein Beispieldokument (Quelle: [Ham03]). 5.2 Neue Elemente in RSS 0.92 Version 0.92 kennt einige neue Elemente: channel: dem channel-element wurden das neue optionale Element cloud hinzugefügt, welches Unterstützung für Publish & Subscribe ermöglicht. Das cloud-element selbst besitzt besitzt fünf Kindelemente, die alle obligatorisch sind und in der XML-Darstellung des Dokuments Attribute des cloud-elements sind 11 : domain: der Server, an den Subscribe-Anfragen gesendet werden sollen. port: der Port des Servers, über den die Anfrage gesendet werden soll. path: der volle auf dem Server aufzurufende Pfad für Subscribe-Anfragen. 11 Warum hier von den vorher verwendeten Konventionen Abstand genommen wurde, ist unklar. 14

19 <?xml version="1.0" encoding="iso "?> <rss version="0.92"> <channel> <>RSS 0.92 Example</> <> <description>this is an example RSS0.91 feed</description> <language>en-gb</language> <copyright>copyright 2002, Oreilly and Associates.</copyright> <rating> <!-- See the text --> </rating> <pubdate>03 Apr GMT</pubDate> <lastbuilddate>03 Apr GMT</lastBuildDate> <docs> <skipdays> <day>monday</day> </skipdays> <skiphours> <hour>20</hour> </skiphours> <cloud domain=" port="80" path="/rpc2" registerprocedure="pleasenotify" protocol="xml-rpc" /> <image> <>RSS 0.92 Example</> <url> <> <width>88</width> <height>31</height> <description>the World s Leading Technical Publisher</description> </image> <textinput> <>Search</> <description>search the Archives</description> <name>query</name> <> </textinput> <item> <>The First Item</> <> <description>this is the first item.</description> <source url=" Site</source> <enclosure url=" length="54321" type="audio/mpeg"/> <category domain=" Business/Industries/Publishing/Publishers/ Nonfiction/</category> </item> <item> <>The Second Item</> <> <description>this is the second item.</description> <source url=" Site</source> <enclosure url=" length="54321" type"audio/mpeg"/> <category domain=" Business/Industries/Publishing/Publishers/Nonfiction/</category> </item> </channel> </rss> Abbildung 7: Beispieldokument RSS

20 protocol: das für die Anfrage zu verwendende Protokoll. Hier sind die Werte xml-rpc und soap zulässig in der Praxis wird aber ausschließlich XML-RPC verwendet 12. registerprocedure: die für die Anfrage zu verwendende serverseitige Funktion. Ein Beispiel für ein cloud-element findet sich in Abb. 7, die Publish & Subscribe - Mechanismen werden in Kapitel 9 näher erläutert. item: dieses Element erhielt drei neue Kindelemente, die weitere Metadaten zur Verfügung stellen und das Einbinden von Multimedia-Inhalten ermöglichen: source (optional, maximal 1): enthält die ursprüngliche Quelle des Items. Dies ist beispielsweise nützlich, wenn der empfangene Feed von einem Aggregator stammt, der selbst wiederum andere RSS-Feeds empfängt, zusammenfaßt, filtert etc. 13 Das Element hat ein (obligatorisches) Attribut namens url, welches einen URL zur Quelle bezeichnet. Der Inhalt des Elements selbst ist der Name der Quelle. category (optional, maximal 1): enthält die Kategorie, in die der Inhalt des Items einzubinden ist. Das (obligatorische) Attribut domain enthält dabei die Taxonomie, innerhalb der die Kategorisierung stattfindet, z.b. enclosure (optional, maximal 1): mit diesem Element ist es möglich, beliebige Inhalte, z.b. Multimedia- Daten, mit einem Item zu assoziieren. Das Element hat drei obligatorische Attribute, url (den URL zu einer Datei), length (die Länge der Datei) und type (den Datentyp) der Datei. 5.3 Weitere Änderungen in RSS 0.92 Obwohl die in RSS 0.92 neu hinzugekommenen Elemente neue Möglichkeiten eröffnen, ist die vielleicht wichtigere Neuerung das Entfernen vieler Einschränkungen der Vorgängerversionen: Sämtliche Textlängenbeschränkungen wurden entfernt. Das bedeutet, daß der Inhalt aller Elemente in RSS 0.92 prinzipiell beliebig lang werden darf. Wegfall der Beschränkung auf 15 item-elemente innerhalb eines Channels. Ein Channel darf beliebig viele Items enthalten XML-RPC ist ein Protokoll, das den Datenaustausch auch von komplexen Datenstrukturen über ein Netzwerk ermöglicht. 13 Für weitere Informationen zu Aggregatoren siehe Kapitel In der Praxis sind in fast allen Feeds noch immer maximal 15 Items enthalten. 16

21 Das language-kindelement von channel ist optional. Der Grund dafür ist, daß insbesondere ein aus mehreren anderen Feeds von einem Aggregator zusammengestellter Feed Items in mehreren verschiedenen Sprachen enthalten kann und somit nicht eine einzelne Sprache festgelegt werden kann. Sämtliche Kindelemente von item sind optional. Den Ausschlag für diese Entscheidung gab wohl die Affinität des Entwicklers zu Weblogs: When a RSS file reflects the content of a weblog or blog site, the structure required by previous versions of RSS was often impossible to synthesize. For example, there is no actual limit on the number of s a weblog item can have. [RSS092] Trotz all dieser Neuerungen ist dank der Art der Änderungen RSS 0.92 abwärtskompatibel zu Version RSS 1.0 Es besteht kein Zweifel, daß Dave Winer mit seiner Arbeit viel zur Entwicklung von RSS beigetragen hat. Nichtsdestotrotz gab es innerhalb der Entwicklergemeinde weiterhin Meinungsverschiedenheiten darüber, ob das Format ein möglichst einfaches, nicht RDF-basiertes Datenmodell verwenden sollte (die Philosophie hinter den Versionen 0.9x), oder ob nicht doch ein etwas komplexeres, auf RDF basierendes Modell inklusive dessen mächtigen Möglichkeiten im Hinblick auf Erweiterungen vorzuziehen sei. Ein Argument für letzteren Standpunkt ist im Nachhinein die immer größer werdende Menge an Elementen in der 0.9x - Linie, die eben durch die starre, nicht erweiterbare Spezifikation gegeben war: sobald neue Funktionalität benötigt wird, muß das Format erweitert und damit geändert werden. Im Dezember 2000 schufen die Entwickler der rss-dev-mailingliste Fakten und veröffentlichten die Spezifikation von RSS 1.0, eine komplett RDF-kompatible Version von RSS. 6.1 Struktur von RSS 1.0 Abb. 8 zeigt die Struktur eines RSS Dokuments (Änderungen gegenüber der Version 0.9 sind farblich markiert), Abb. 9 ein einfaches Beispiel (Quelle: [Ham03]). Auffällig ist die im Gegensatz zu RSS 0.91 geradezu übersichtliche Struktur, die mit einem Minimum an Erweiterungen im Vergleich zur Version 0.9 auskommt. Dem item-element wird lediglich ein Kindelement namens description hinzugefügt, welches die gleiche Bedeutung wie in RSS 0.92 hat. Die Änderungen im channel-element sind durch die Struktur eines RDF-Dokuments nötig geworden. In einem RDF-Dokument müssen alle Ressourcen, über die Aussagen getroffen werden, in der obersten Hierarchie-Ebene des Dokuments direkt unter dem Wurzelknoten liegen. Dies war in der ersten Version von RSS 0.9 schon der Fall (eben weil diese Version teilweise auf RDF basierte). Version 1.0 fügt nun lediglich innerhalb des channel-elements Verweise zu diesen 17

22 rdf:rdf channel textinput image item description description url name description textinput image items Abbildung 8: Struktur von RSS 1.0 Ressourcen hinzu; dies wird daran ersichtlich, daß die rdf:resource-attribute der Elemente image, textinput und der Liste innerhalb des Elements items 15 identisch mit den rdf:about-attributen der jeweils referenzierten Elemente auf der obersten Ebene sind. 6.2 Module in RSS 1.0 Auffällig an einem RSS 1.0-Dokument sind (wie im Beispiel, Abb. 9) die vielen Elemente, die im Dokument vorhanden sind, aber nicht in der RSS-Spezifikation auftauchen. Dies ist genau der Mechanismus, mit dem Erweiterbarkeit erreicht wird: Module werden einfach verwendet, indem ihr Namespace im XML-Dokument deklariert wird (im Beispiel direkt im Wurzelelement rdf:rdf) und die im Modul verfügbaren Elemente in das Dokument eingefügt werden. Welche Elemente dabei in welchem Zusammenhang (an welcher Stelle im Dokument) verwendet werden dürfen, wird dabei in der Modulspezifikation festgelegt. Es folgt eine kurze Beschreibung einiger wichtiger oder interessanter Module 16 mod dublincore, Namespace-Präfix dc Dieses Modul stellt Unterstützung für die erweiterten Metadaten der Dublin Core Metadata Initiative bereit; es ist wohl das am meisten verwendete Modul und im Zusammenhang mit der Idee des Semantic Web zu sehen: nur wenn so viele Informationen wie möglich über die im Dokument enthaltenen Daten angegeben werden, wird diese Vision möglicherweise realisierbar. Dementsprechend erlaubt es dieses Modul, eine Fülle von Informationen über Ressourcen zu definieren, z.b. Urheber, Beschreibung, Art der Ressource, Kontext und vieles mehr. mod syndication, Namespace-Präfix sy Dieses Modul definiert lediglich drei neue Elemente für das channel- Element, die allerdings eine wichtige Funktion erfüllen: sie geben dem 15 Das items-element stellt einfach eine geordnete Liste mit Verweisen auf Ressourcen dar. 16 Natürlich gibt es noch eine Vielzahl anderer Module für verschiedenste Anwendungsgebiete. 18

23 <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns:dc=" xmlns:sy=" xmlns:co=" xmlns:ti=" xmlns=" <channel rdf:about=" <>Meerkat</> <> <description>meerkat: An Open Wire Service</description> <dc:publisher>the O Reilly Network</dc:publisher> <dc:creator>rael Dornfest (mailto:rael@exampleurl.com)</dc:creator> <dc:rights>copyright 2000 O Reilly & Associates, Inc.</dc:rights> <dc:date> t12:00+00:00</dc:date> <sy:updateperiod>hourly</sy:updateperiod> <sy:updatefrequency>2</sy:updatefrequency> <sy:updatebase> t12:00+00:00</sy:updatebase> <image rdf:resource=" /> <textinput rdf:resource=" /> <items> <rdf:seq> <rdf:li rdf:resource=" /> </rdf:seq> </items> </channel> <image rdf:about=" <>Meerkat Powered!</> <url> <> </image> <textinput rdf:about=" <>Search Meerkat</> <description>search Meerkat s RSS Database...</description> <name>s</name> <> <ti:function>search</ti:function> <ti:inputtype>regex</ti:inputtype> </textinput> <item rdf:about=" <>XML: A Disruptive Technology</> <> <dc:description>this the description of the article</dc:description> <dc:publisher>the O Reilly Network</dc:publisher> <dc:creator>simon St.Laurent (mailto:simonstl@simonstl.com)</dc:creator> <dc:rights>copyright 2000 O Reilly & Associates, Inc.</dc:rights> <dc:subject>xml</dc:subject> <co:name>xml.com</co:name> <co:market>nasdaq</co:market> <co:symbol>xml</co:symbol> </item> </rdf:rdf> Abbildung 9: Beispieldokument RSS

24 <?xml version="1.0" encoding="utf-8"?> <rdf:rdf xmlns:rdf=" xmlns=" xmlns:ss=" <channel rdf:about=" <>An Example</> <description>just an example of system statuses</description> <> <ss:aboutstats> <items> <rdf:seq> <rdf:li resource=" /> <rdf:li resource=" /> </rdf:seq> </items> </channel> <item rdf:about=" <>Website</> <> <ss:responding>true</ss:responding> <ss:lastchecked> t19:20: :00</ss:lastchecked> <ss:lastseen> t19:20: :00</ss:lastseen> <ss:availability>85</ss:availability> <ss:averageresponsetime>5.2</ss:averageresponsetime> </item> <item rdf:about=" <>Database server</> <> <ss:responding>false</ss:responding> <ss:lastchecked> t19:20: :00</ss:lastchecked> <ss:lastseen> t13:43: :00</ss:lastseen> <ss:availability>77</ss:availability> <ss:averageresponsetime>12.2</ss:averageresponsetime> <ss:statusmessage>engineers are investigating.</ss:statusmessage> </item> </rdf:rdf> Abbildung 10: Beispieldokument RSS 1.0 mit mod servicestatus Anwender einen Anhaltspunkt, wie oft sich die Informationen im Channel etwa ändern. Bei großen Nachrichtenseiten kann es durchaus sinnvoll sein, alle 10 Minuten auf Aktualisierungen zu prüfen, bei anderen Feeds ist eine Aktualisierung mehr als einmal täglich unwahrscheinlich. Im Beispieldokument etwa wird festgelegt, daß ein sinnvolles Intervall für die Überprüfung 30 Minuten beträgt (2 Mal pro Stunde). 17 mod servicestatus, Namespace-Präfix ss Dies ist ein Modul, das wahrscheinlich recht selten verwendet wird, aber die Flexibilität des modulbasierten, erweiterbaren Ansatzes von RSS 1.0 glänzend demonstriert. Das Modul ermöglicht es, Informationen über die Erreichbarkeit von Servern in einem RSS-Stream bereitzustellen. Abb. 10 zeigt ein Beispiel für die Verwendung (Quelle: [Ham03]). 17 Auf diese Problematik wird im Kapitel 9 näher eingegangen. 20

25 rss version= 2.0 channel description language copyright rating docs webmaster pubdate managinged. lastbuildd. ttl generator textinput description name cloud domain port path protocol registerprocedure image url width height description skipdays day skiphours hour item description source url category domain enclosure url length type author comments pubdate guid ispermalink Abbildung 11: Struktur von RSS 2.0 Die Vorteile der Module liegen auf der Hand: die Basisspezifikation von RSS bleibt schlank, ist aber trotzdem nahezu für beliebige Einsatzzwecke erweiterbar. Eine weitere angenehme Eigenschaft ist, daß Anwendungen auch Feeds verarbeiten können, die Module verwenden, die die Anwendung nicht kennt sie ignorieren deren Elemente einfach; die korrekte Grundstruktur des Feeds bleibt dennoch erhalten. Anwendungen, die die eingesetzten Module kennen, können die Zusatzinformationen auswerten. 7 RSS 2.0 Ungefähr zwei Jahre, nachdem RSS 1.0 erschien, wurde die Nachfolgerversion von RSS 0.92 veröffentlicht. Diese Version, die ursprünglich die Nummer 0.94 trug, dann aber in Version 2.0 umgetauft wurde, folgte den Vorgängern ihrer Entwicklungslinie, indem sie weiter komplett ohne RDF auskam. Allerdings wurden Teile der Konzepte von RSS 1.0 integriert, wie die Unterstützung von XML Namespaces und damit Module. Diese waren aber wiederum mit den Modulen der Version 1.0 nicht kompatibel, wie auch das komplette Datenmodell verschieden vom RDF-basierten Modell blieb. 7.1 Struktur von RSS 2.0 Abb. 8 zeigt die Struktur eines RSS 2.0-Dokuments. Änderungen im Vergleich zur Version 0.92 sind farblich markiert. 21

26 7.2 Änderungen in RSS 2.0 Eine wesentliche Neuerung im Vergleich zu den Versionen 0.9x ist die Möglichkeit der Verwendung von Modulen, die vom Prinzip sehr ähnlich funktioniert wie in RSS 1.0 (siehe Abschnitt 6.2). Desweiteren sind auch in dieser Version wieder neue Elemente hinzugefügt worden, die im Folgenden kurz beschrieben werden. channel: dem channel-element wurden zwei Elemente hinzugefügt: ttl (optional, maximal 1): bezeichnet die Anzahl der Minuten, die das vom Feed erhaltene Dokument im Cache gehalten werden darf, bevor es vom Ursprungsserver neu geladen werden muß. generator (optional, maximal 1): das Programm, mit dem der Feed erzeugt wurde. item: dem item-element wurden mehrere Elemente hinzugefügt, hauptsächlich, um weitere Metadaten definieren zu können: author (optional, maximal 1): die -Adresse des Autors des Items. comments (optional, maximal 1): bezeichnet einen URL mit Kommentaren zu diesem Item. pubdate (optional, maximal 1): der Zeitstempel der Erstellung des Items. guid (optional, maximal 1): (guid: globally unique identifier) ein eindeutiger Bezeichner für das Item, konzeptuell ähnlich dem URI (siehe Abschnitt 2.3). Wenn dieses Element ein Attribut mit dem Namen ispermalink und dem Wert true hat, so bedeutet das, daß der Wert des guid ein URL ist. RSS 2.0 hat den Vorteil der Erweiterungsmöglichkeit durch Module von RSS 1.0 aufgegriffen; allerdings wirkt die Umsetzung weniger elegant als bei Version 1.0, die durch ein minimalistisches Grundgerüst und Auslagerung sämtlicher anderer Funktionalität in Module überzeugt. Version 2.0 wurde vom Entwickler als letzte Version dieses Zweigs deklariert, so daß hier keine Weiterentwicklungen zu erwarten sind. 8 Clients für RSS Nachdem die Entwicklung der verschiedenen Versionen etwas chaotisch erscheint, mag der Eindruck entstanden sein, daß es schwierig sein muß, Programme zu entwickeln, die als RSS-Client das heißt, als Programm, das RSS-Dateien von Servern anfordert und verarbeitet mit jedem der Standards umgehen können. Zwar unterstützen nur wenige gängige Programme RSS 2.0, die prinzipiellen Schwierigkeiten einer umfassenden Implementierung sind aber eher gering, da: 22

27 für die meisten Anwendungen eine Beschränkung auf die wichtigsten in RSS 0.9 oder 0.91 definierten Elemente genügt, zumal ein Großteil der Feeds sich auch auf diese beschränkt die Versionen 2.0 und 0.92 voll abwärtskompatibel sind wenn eine Anwendung z.b. mit RSS 2.0 umgehen kann, versteht sie automatisch alle Feeds, die in den Versionen 0.91 und 0.92 gesendet werden die Version 1.0 zur Version 0.9 abwärtskompatibel ist, wenn man nicht auf korrektem RDF besteht die Unterschiede bei den Kernelementen gering sind (Name des Wurzelelements rdf:rdf oder rss, Elemente als Kinder von rdf:rdf bzw. channel) so gut wie jede Programmiersprache XML-Unterstützung bietet. Diesen Fakten ist es wohl zu verdanken, daß eine Vielzahl von zumeist kostenlosen RSS-Clients existiert. Die Anwendungen lassen sich grundsätzlich in zwei Kategorien einteilen: sogenannte Aggregatoren und klassische Clients, die auf dem Rechner des Anwenders laufen. 8.1 Aggregatoren Unter einem Aggregator versteht man im weitesten Sinne einen Dienst, der andere Dienste zusammenfaßt und dem Nutzer anbietet (Aggregation: Vereinigung von Molekülen zu Molekülverbindungen). 18 Dabei agiert der Dienst selbst als Client gegenüber den angebotenen Feeds und bietet diese dem Nutzer dann z.b. in zusammengefaßter oder gefilterter Form an. Ein typisches Beispiel für solch einen Aggregator ist Meerkat [ORM]). Abb. 12 zeigt eine Ausgabe von Meerkat; dieser Aggregator unterstützt die Ausgabe der Suchergebnisse in verschiedenen Formaten, das Beispiel zeigt eine Ausgabe als minimalistisches HTML. Die wohl interessanteste Möglichkeit dabei ist, die Ausgabe selbst wiederum als RSS anzufordern und mit einem normalen Client anzuschauen. 8.2 Desktop-Clients Die andere verbreitete Sorte von RSS-Clients sind Programme, die lokal beim Benutzer installiert werden. Diese bieten dann unter Umständen fortgeschrittene Optionen wie eine automatische Aktualisierung der abonnierten Channels, das Ausblenden schon gelesener Beiträge etc. Abb. 13 zeigt eine Beispielausgabe von Hotsheet [HSC] mit zwei abonnierten Channels. 18 Manche Leute bezeichnen jedes Programm, das RSS-Feeds irgendwie verarbeitet und dem Nutzer darbietet, als Aggregator. Hier wird die feinere Unterscheidung verwendet. 23

28 Abbildung 12: Beispiel RSS-Aggregator Meerkat Abbildung 13: Beispiel RSS-Client Hotsheet 24