RSS - Nachrichtendienste für Jedermann

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 [email protected]
Januar 2004
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.
”
Inhaltsverzeichnis
1 Einleitung
1
2 Allgemeines zu RSS
1
2.1
RSS: ein XML-basiertes Datenformat . . . . . . . . . . . . . . . .
2
2.2
Übertragung von RSS-Dateien . . . . . . . . . . . . . . . . . . .
3
2.3
Wichtige Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.4
Entwicklung von RSS . . . . . . . . . . . . . . . . . . . . . . . .
4
3 RSS 0.9
3.1
Struktur von RSS 0.9
4 RSS 0.91
5
. . . . . . . . . . . . . . . . . . . . . . . .
7
10
4.1
Struktur von RSS 0.91 . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2
Neue Elemente in RSS 0.91 . . . . . . . . . . . . . . . . . . . . . 10
5 RSS 0.92
13
5.1
Struktur von RSS 0.92 . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2
Neue Elemente in RSS 0.92 . . . . . . . . . . . . . . . . . . . . . 14
5.3
Weitere Änderungen in RSS 0.92 . . . . . . . . . . . . . . . . . . 16
6 RSS 1.0
17
6.1
Struktur von RSS 1.0
6.2
Module in RSS 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 RSS 2.0
. . . . . . . . . . . . . . . . . . . . . . . . 17
21
7.1
Struktur von RSS 2.0
7.2
Änderungen in RSS 2.0 . . . . . . . . . . . . . . . . . . . . . . . 22
8 Clients für RSS
. . . . . . . . . . . . . . . . . . . . . . . . 21
22
8.1
Aggregatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.2
Desktop-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9 Publish & Subscribe
25
9.1
Publish & Subscribe mit RSS 0.92 und 2.0 . . . . . . . . . . . . . 25
9.2
Publish & Subscribe mit RSS 1.0 . . . . . . . . . . . . . . . . . . 26
9.3
Bemerkungen zu Publish & Subscribe . . . . . . . . . . . . . . . 26
10 Zusammenfassung
27
A Glossar
28
B Wichtige Internetadressen
29
C Abkürzungen und Akronyme
29
Literaturverzeichnis
30
Index
31
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 Sei”
ten 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
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 XMLParser1 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 ein”
her 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
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 Header2 mit. Der empfohlene Content-Type für RSS ist application/xml+rdf. Es wird außerdem empfohlen, als Dateiendung für RSSDateien .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ört3 .
Jedes Item enthält Informationen zu einer Ressource (bei Nachrichten-Feeds
etwa zu einem bestimmten Artikel, bei Weblogs4 zu einem Eintrag etc.).
Eine Ressource ist ein abstraktes Konzept für Irgendetwas, das eindeutig iden”
tifiziert 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 RSSDokuments ersichtlich, insbesondere nicht in der Version 0.9 (siehe Kapitel 3).
4
Ein Weblog ist eine Art Internet-Tagebuch“.
”
3
Resource Locator), d.h. eine Internet-Adresse“, unter der das entsprechende
”
Objekt (Dokument, Bild, Webseite) gefunden werden kann5 .
2.4
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 0.91.
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
Version
0.9
0.91
1.0
0.92
2.0
Erscheinungsdatum
1999
06/2000
12/2000
12/2000
08/2002
RDF-basiert?
ja
nein
ja
nein
nein
RDF-kompatibel?
nein
nein
ja
nein
nein
Module?
nein
nein
ja
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 0.92.
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 definieren6 [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
damals zu erreichen unter http://my.netscape.com – 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
rdf:RDF
channel
textinput
image
item
title
title
title
title
description
description
url
link
link
name
link
link
Abbildung 2: Struktur von RSS 0.9
3.1
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-Element7 .
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:
– title (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.
– link (obligatorisch, 1)
In diesem Element findet sich ein URL, der auf die Webseite des FeedAnbieters 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 statt7
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
dessen) angezeigt werden kann. Das image-Element hat folgende Kindelemente:
– title (obligatorisch, 1)
Dieses Element wurde in der Spezifikation verwendet, um das altAttribut 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.
– link (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:
– title (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).
– link (obligatorisch, 1)
Dieses Element enthält den URL, an den die vom Benutzer eingegebenen Daten gesendet werden. Von Netscape wurde nur die GETMethode zur Übergabe von Daten unterstützt8 . 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 link-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
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://my.netscape.com/rdf/simple/0.9/">
<channel>
<title>Mozilla Dot Org</title>
<link>http://www.mozilla.org</link>
<description>the Mozilla Organization web site</description>
</channel>
<image>
<title>Mozilla</title>
<url>http://www.mozilla.org/images/moz.gif</url>
<link>http://www.mozilla.org</link>
</image>
<item>
<title>New Status Updates</title>
<link>http://www.mozilla.org/status/</link>
</item>
<item>
<title>Bugzilla Reorganized</title>
<link>http://www.mozilla.org/bugs/</link>
</item>
<item>
<title>Mozilla Party, 2.0!</title>
<link>http://www.mozilla.org/party/1999/</link>
</item>
<item>
<title>Unix Platform Parity</title>
<link>http://www.mozilla.org/build/unix.html</link>
</item>
<item>
<title>NPL 1.0M published</title>
<link>http://www.mozilla.org/NPL/NPL-1.0M.html</link>
</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:
– title (obligatorisch, 1)
Der Titel (die Überschrift) des Items. Dieser Text wird dem Anwender angezeigt und darf bis zu 100 Zeichen lang sein.
– link (obligatorisch, 1)
Hier wird der URL eingetragen, auf den das Item verlinkt 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
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 waren9 . Der Verzicht auf RDF brachte eine Umstrukturierung des Aufbaus der Datei mit sich– dadurch war das neue Format nicht
abwärtskompatibel10 .
4.1
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
rss
version=0.91
channel
title
textinput
image
item
description
title
title
title
link
description
url
link
language
name
link
description
copyright
link
width
rating
height
docs
description
webMaster
skipDays
day
pubDate
managingEditor
skipHours
lastBuildDate
hour
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 Email-Adresse des Verantwortlichen für den Inhalt des Channels
(höchstens 100 Zeichen). Das empfohlene Format ist
[email protected] (Vorname Nachname).
– webMaster (optional, höchstens 1):
die Email-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
<?xml version="1.0" encoding="ISO-8859-1" ?>
<rss version="0.91">
<channel>
<title>RSS0.91 Example</title>
<link>http://www.exampleurl.com/example/index.html</link>
<description>This is an example RSS0.91 feed</description>
<language>en-gb</language>
<copyright>Copyright 2002, Oreilly and Associates.</copyright>
<managingEditor>[email protected]</managingEditor>
<webMaster>[email protected]</webMaster>
<rating></rating>
<pubDate>03 Apr 02 1500 GMT</pubDate>
<lastBuildDate>03 Apr 02 1500 GMT</lastBuildDate>
<docs>http://backend.userland.com/rss091</docs>
<skipDays>
<day>Monday</day>
</skipDays>
<skipHours>
<hour>20</hour>
</skipHours>
<image>
<title>RSS0.91 Example</title>
<url>http://www.exampleurl.com/example/images/logo.gif</url>
<link>http://www.exampleurl.com/example/index.html</link>
<width>88</width>
<height>31</height>
<description>Computer Books, Conferences, Online Publishing</description>
</image>
<textInput>
<title>Search</title>
<description>Search our website</description>
<name>searchstring</name>
<link>http://www.exampleurl.com/example/search.pl</link>
</textInput>
<item>
<title>The First Item</title>
<link>http://www.exampleurl.com/example/001.html</link>
<description>This is the first item.</description>
</item>
<item>
<title>The Second Item</title>
<link>http://www.exampleurl.com/example/002.html</link>
<description>This is the second item.</description>
</item>
<item>
<title>The Third Item</title>
<link>http://www.exampleurl.com/example/003.html</link>
<description>This is the third item.</description>
</item>
</channel>
</rss>
Abbildung 5: Beispieldokument RSS 0.91
12
soll. Das skipDays-Element kann bis zu sieben day-Kindelemente enthalten, die einen der Werte (Monday, Tuesday, Wednesday,
Thursday, Friday, Saturday, Sunday) haben. Das skipHoursElement 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
title-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 verlinkten Ressource darstellen – bei
Nachrichten-Feeds etwa eine kurze Zusammenfassung des Artikels, zusätzlich zur im title-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
rss
version=0.92
channel
title
textinput
image
item
description
title
title
title
link
description
url
link
language
name
link
description
copyright
link
width
source
rating
cloud
height
url
docs
domain
webMaster
port
skipDays
pubDate
path
day
enclosure
managingEd.
protocol
skipHours
url
lastBuildD.
description
registerProcedure
hour
category
domain
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 sind11 :
– 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
<?xml version="1.0" encoding="ISO-8859-1" ?>
<rss version="0.92">
<channel>
<title>RSS 0.92 Example</title>
<link>http://www.oreilly.com/example/index.html</link>
<description>This is an example RSS0.91 feed</description>
<language>en-gb</language>
<copyright>Copyright 2002, Oreilly and Associates.</copyright>
<managingEditor>[email protected]</managingEditor>
<webMaster>[email protected]</webMaster>
<rating> <!-- See the text --> </rating>
<pubDate>03 Apr 02 1500 GMT</pubDate>
<lastBuildDate>03 Apr 02 1500 GMT</lastBuildDate>
<docs>http://backend.userland.com/rss091</docs>
<skipDays>
<day>Monday</day>
</skipDays>
<skipHours>
<hour>20</hour>
</skipHours>
<cloud domain="http://www.oreilly.com" port="80" path="/RPC2"
registerProcedure="pleaseNotify" protocol="xml-rpc" />
<image>
<title>RSS 0.92 Example</title>
<url>http://www.oreilly.com/example/images/logo.gif</url>
<link>http://www.oreilly.com/example/index.html</link>
<width>88</width>
<height>31</height>
<description>The World’s Leading Technical Publisher</description>
</image>
<textInput>
<title>Search</title>
<description>Search the Archives</description>
<name>query</name>
<link>http://www.oreilly.com/example/search.cgi</link>
</textInput>
<item>
<title>The First Item</title>
<link>http://www.oreilly.com/example/001.html</link>
<description>This is the first item.</description>
<source url="http://www.anothersite.com/index.xml">Another Site</source>
<enclosure url="http://www.oreilly.com/001.mp3" length="54321" type="audio/mpeg"/>
<category domain="http://www.dmoz.org"> Business/Industries/Publishing/Publishers/
Nonfiction/</category>
</item>
<item>
<title>The Second Item</title>
<link>http://www.oreilly.com/example/002.html</link>
<description>This is the second item.</description>
<source url="http://www.anothersite.com/index.xml">Another Site</source>
<enclosure url="http://www.oreilly.com/002.mp3" length="54321" type"audio/mpeg"/>
<category domain="http://www.dmoz.org">
Business/Industries/Publishing/Publishers/Nonfiction/</category>
</item>
</channel>
</rss>
Abbildung 7: Beispieldokument RSS 0.92
15
– 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 verwendet12 .
– 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. http://www.dmoz.org.
– enclosure (optional, maximal 1):
mit diesem Element ist es möglich, beliebige Inhalte, z.B. MultimediaDaten, 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 enthalten14 .
12
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 8.
14
In der Praxis sind in fast allen Feeds noch immer maximal 15 Items enthalten.
16
• 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 links a
weblog item can have.“ [RSS092]
Trotz all dieser Neuerungen ist – dank der Art der Änderungen – RSS 0.92
abwärtskompatibel zu Version 0.91.
6
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-1.0 - 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
rdf:RDF
channel
textinput
image
item
title
title
description
description
url
link
link
name
link
description
textinput
link
title
title
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 items15
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 Module16
• 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 channelElement, die allerdings eine wichtige Funktion erfüllen: sie geben dem
15
Das items-Element stellt einfach eine geordnete Liste mit Verweisen auf Ressourcen dar.
Natürlich gibt es noch eine Vielzahl anderer Module für verschiedenste Anwendungsgebiete.
16
18
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:co="http://purl.org/rss/1.0/modules/company/"
xmlns:ti="http://purl.org/rss/1.0/modules/textinput/"
xmlns="http://purl.org/rss/1.0/">
<channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0">
<title>Meerkat</title>
<link>http://meerkat.oreillynet.com</link>
<description>Meerkat: An Open Wire Service</description>
<dc:publisher>The O’Reilly Network</dc:publisher>
<dc:creator>Rael Dornfest (mailto:[email protected])</dc:creator>
<dc:rights>Copyright &#169; 2000 O’Reilly &amp; Associates, Inc.</dc:rights>
<dc:date>2000-01-01T12:00+00:00</dc:date>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>2</sy:updateFrequency>
<sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>
<image rdf:resource="http://meerkat.oreillynet.com/icons/meerkat-powered.jpg" />
<textinput rdf:resource="http://meerkat.oreillynet.com" />
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://c.moreover.com/click/here.pl?r123" />
</rdf:Seq>
</items>
</channel>
<image rdf:about="http://meerkat.oreillynet.com/icons/meerkat-powered.jpg">
<title>Meerkat Powered!</title>
<url>http://meerkat.oreillynet.com/icons/meerkat-powered.jpg</url>
<link>http://meerkat.oreillynet.com</link>
</image>
<textinput rdf:about="http://meerkat.oreillynet.com">
<title>Search Meerkat</title>
<description>Search Meerkat’s RSS Database...</description>
<name>s</name>
<link>http://meerkat.oreillynet.com/</link>
<ti:function>search</ti:function>
<ti:inputType>regex</ti:inputType>
</textinput>
<item rdf:about="http://c.moreover.com/click/here.pl?r123">
<title>XML: A Disruptive Technology</title>
<link>http://c.moreover.com/click/here.pl?r123</link>
<dc:description>This the description of the article</dc:description>
<dc:publisher>The O’Reilly Network</dc:publisher>
<dc:creator>Simon St.Laurent (mailto:[email protected])</dc:creator>
<dc:rights>Copyright &#169; 2000 O’Reilly &amp; 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 1.0
19
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://purl.org/rss/1.0/"
xmlns:ss="http://purl.org/rss/1.0/modules/servicestatus/">
<channel rdf:about="http://my.organisation.com">
<title>An Example</title>
<description>Just an example of system statuses</description>
<link>http://my.organisation.com</link>
<ss:aboutStats>http://my.organisation.com/status.html</ss:aboutStats>
<items>
<rdf:Seq>
<rdf:li resource="http://my.organisation.com/website" />
<rdf:li resource="http://my.organisation.com/database" />
</rdf:Seq>
</items>
</channel>
<item rdf:about="http://my.organisation.com/website">
<title>Website</title>
<link>http://my.organisation.com/website</link>
<ss:responding>true</ss:responding>
<ss:lastChecked>2002-05-10T19:20:30.45+01:00</ss:lastChecked>
<ss:lastSeen>2002-05-10T19:20:30.45+01:00</ss:lastSeen>
<ss:availability>85</ss:availability>
<ss:averageResponseTime>5.2</ss:averageResponseTime>
</item>
<item rdf:about="http://my.organisation.com/database">
<title>Database server</title>
<link>http://my.organisation.com/database</link>
<ss:responding>false</ss:responding>
<ss:lastChecked>2002-05-10T19:20:30.45+01:00</ss:lastChecked>
<ss:lastSeen>2002-05-09T13:43:56.24+01: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
rss
version= 2.0
channel
title
description
link
language
copyright
rating
docs
webMaster
pubDate
managingEd.
lastBuildD.
ttl
generator
textinput
title
description
name
link
cloud
domain
port
path
protocol
registerProcedure
image
title
url
link
width
height
description
skipDays
day
skipHours
hour
item
title
link
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
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 Email-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
• 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
Abbildung 12: Beispiel RSS-Aggregator Meerkat
Abbildung 13: Beispiel RSS-Client Hotsheet
24
9
Publish & Subscribe
Da RSS auf HTTP aufsetzt, ist eine Implementierung mit gängigen Programmiersprachen relativ einfach. Es stellt sich allerdings ein Problem: HTTP ist
zustandslos – das heißt, ein Client sendet eine Anfrage an den Server, der Server sendet eine Antwort, dann wird die Verbindung getrennt und die Kommunikationspartner sind wieder in einem Zustand, als wären sie nie miteinander
in Verbindung getreten. Der Client hat also keine andere Möglichkeit herauszufinden, ob neue Daten auf dem Server vorliegen, als erneut eine Verbindung
zum Server aufzubauen und die Daten des Feeds herunterzuladen.
Das Problem ist klar: der Client will möglichst aktuelle Informationen, weiß aber
nicht, wann eigentlich neue Informationen vorliegen – er kann nur nachschauen.
Überprüft ein Client zu oft den Server auf neue Daten, so entsteht unnötig
viel Netzverkehr. Prüft er hingegen zu selten, entgehen ihm vielleicht wichtige
Informationen.
Dieses Dilemma läßt sich mit HTTP allein nicht zufriedenstellend lösen. Verschiedene Ansätze, wie z.B. das Modul mod syndication (siehe Absatz 6.2)
erlauben es, dem Client zumindest einen Anhaltspunkt für einen sinnvollen
Zeitabstand zwischen erneuten Anfragen zu geben. Eine wesentlich elegantere Lösung wäre allerdings, wenn der Server den Clients mitteilen würde, wenn
neue Informationen vorliegen. Dieser Ansatz wird Publish & Subscribe (deutsch
etwa: Veröffentlichung und Abonnement) genannt.
Bei diesem Konzept veröffentlicht der Server die Adresse, wo sich Clients für
den gewünschten Feed abonnieren können; bei einer Änderung des Inhalts des
Channels sendet dann der Server allen abonnierten Clients eine Nachricht, so
daß diese quasi nur auf Aufforderung den Feed neu laden.
9.1
Publish & Subscribe mit RSS 0.92 und 2.0
Mit RSS 0.92 wurde das cloud-Element eingeführt. In diesem werden alle für
den Client notwendigen Informationen übermittelt, um ihm ein Abonnieren
des Channels zu ermöglichen. Beim Abonnieren wiederum teilt der Client dem
Server mit, wie dieser ihn erreichen kann. Als Beispiel diene folgendes cloudElement:
<cloud domain="www.rsssite.com" port="80" path="/subscr.pl"
registerProcedure="subscribeToFeeds" protocol="xml-rpc" />
Will ein Client sich bei diesem Server anmelden, so ruft er die angegebene
Funktion auf und übergibt dabei dem Server die Informationen, wohin dieser
im Falle einer Änderung die Nachricht senden soll, zum Beispiel folgendermaßen
(Pseudocode):
25
http://www.rsssite.com:80/subscr.pl!subscribeToFeeds(
"RSSFeedHasChanged", /* lokale Callback-Prozedur */
8889,
/* lokaler Port */
"/XML-RPC/RssWatch", /* lokaler Pfad */
"xml-rpc",
/* Protokoll fuer Callback */
/* Liste der zu ueberwachenden URLS */)
("http://feeds.rsssite.com/feed.php?id=23&ver=0.92")
)
Der Server kennt durch diesen Aufruf die Adresse des Clients, an die die Nachrichten geschickt werden sollen (z.B. my.client.com) – falls also eine Benachrichtigung an den Client gesendet werden soll, so wird diese wie folgt aussehen
(Pseudocode):
http://my.client.com:8889/XML-RPC/RssWatch!RSSFeedHasChanged(
/* veraenderter Feed */)
("http://feeds.rsssite.com/feed.php?id=23&ver=0.92")
)
Daraufhin kann der Client den übergebenen Parameter auswerten und den Feed
beim Server neu anfordern.
9.2
Publish & Subscribe mit RSS 1.0
Für RSS 1.0 steht das Modul mod changedpage bereit, das die gleichen Funktionalitäten bietet wie das cloud-Element in RSS 0.92, allerdings nicht XML-RPC
verwendet, sondern das einfachere HTTP POST. Ein Feed, der diese Funktionalität anbietet, bindet das Modul mod changedpage ein und enthält als Kindelement von channel das Element cp:server, etwa in folgender Form:
<channel>
...
<cp:server rdf:resource="http://www.rsssite.com/subscr1.pl" />
</channel>
Ein Client, der sich abonnieren will, sendet dann folgende HTTP-Anfrage:
POST http://www.rsssite.com/subscr1.pl
target=http://feeds.rsssite.com/feed.php?id=23&ver=1.0
responder=http://my.client.com/RssWatch.php
Wenn sich der Feed ändert, sendet der Server diese Anfrage:
POST http://my.client.com/RssWatch.php
url=http://feeds.rsssite.com/feed.php?id=23&ver=1.0
9.3
Bemerkungen zu Publish & Subscribe
Publish & Subscribe ist ein gutes Prinzip, um den Datenverkehr so niedrig
wie möglich zu halten, trotzdem aber immer die aktuellsten Informationen zu
erhalten. Es gibt allerdings einige Schwierigkeiten, die hier kurz skizziert werden
sollen:
26
• ungültige Abonnenten: um zu vermeiden, daß auf dem Server Listen
mit nicht mehr verfügbaren, aber abonnierten Clients entstehen, werden
Abonnements 24 Stunden nach ihrem Eintrag gelöscht. Das bedeutet, daß
sich Clients regelmäßig neu anmelden müssen.
• Clients müssen erreichbar sein: dies bedeutet, daß der Client sowohl
physisch erreichbar sein muß (interne Rechner in Firmennetzen sind beispielsweise durch die Netzwerkkonfiguration in den seltensten Fällen von
”
außen“ – aus dem Internet – zu erreichen) als auch auf Anfragen von außen warten und reagieren muß, was eventuell Sicherheitslücken öffnet.
• Problem der Verfügbarkeit: es gibt schlichtweg kaum Feed-Anbieter,
die Publish & Subscribe ermöglichen.
Dennoch ist dies eine interessante Technik, die eventuell in Zukunft eine breitere
Benutzerbasis finden könnte.
10
Zusammenfassung
RSS hat sich von Version 0.9, einem simplen Format zur Übertragung von
Schlagzeilen, zu einem leichtgewichtigen und universellen Format zum Austausch fast beliebiger Daten gemausert – und das trotz seiner recht konfusen und
kontroversen Entwicklungsgeschichte. Heutzutage gibt es Millionen von FeedAnbietern und eine ständig wachsende Entwickler- und Benutzergemeinde. Die
Chancen auf eine lange Zukunft von RSS stehen also gut.
Um diese Chancen noch zu verbessern und RSS zum endgültigen Durchbruch
nicht nur bei computerbegeisterten Zeitgenossen zu verhelfen, wurde kürzlich
eine Ausschreibung gestartet, die für RSS einen weniger kryptischen Namen
finden soll – die Vorschläge reichen dabei von 2U über HotLink und WebTicker
bis Yank [RNC]. Man darf also gespannt sein, was die Zukunft für RSS noch
bringt.
27
A
Glossar
Channel: Steht für den konzeptuellen Inhalt eines RSS-Feeds.
Client: Bezeichnet ein Programm, das einen Server kontaktiert und von diesem
Informationen anfordert.
HTTP: Hypertext Transfer Protocol, das Protokoll, das die Kommunikation
von Clients und Servern im WWW regelt. Fordert ein Client ein Dokument vom Server an oder beantwortet der Server eine Anfrage, muß diese
Anfrage den Konventionen des HTTP-Protokolls gehorchen.
Feed: Ein über ein Netzwerk angebotener Datenstrom.
Modul: Eine unabhängige inhaltliche oder funktionale Einheit, die nur bei
Bedarf eingebunden wird.
Namespace: Ein XML-Namespace (Namensraum) ist eine Sammlung von Namen, die durch eine URI-Referenz identifiziert wird. Durch die Zuordnung
von Element- oder Attributnamen zu Namensräumen ist es möglich, Informationseinheiten eindeutig zu identifizieren und Namenskonflikte zu vermeiden. Auf diese Weise können gleichlautende Namen mit unterschiedlicher Bedeutung in verschiedenen Vokabularen verwendet werden.
RDF: Das Resource Description Framework (RDF) ist eine Anwendung von
XML. Es dient der Beschreibung von Informationen einer Webressource
(z. B. einer Webseite oder auch einer ganzen Site). RDF erlaubt die Codierung, den Austausch und die Wiederverwendung von strukturierten
Metadaten (Daten über Daten).
RSS: Rich Site Summary, Really Simple Syndication oder RDF Site Summary.
RSS hat sich als das de-facto Standard-Austausch-Format für Web-Inhalte
etabliert (auch Content Syndication). Basierend auf XML stellt RSS allerdings nicht den gesamten Inhalt zur Verfügung, sondern enthält nur
eine Liste der aktuellen Überschriften, wobei die gesamte Nachricht dann
über einen URL abgerufen werden kann.
Server: Bezeichnet ein Programm, das von Clients kontaktiert wird, um diesen
Informationen zurückzuliefern. Oft wird auch der Rechner, auf dem ein
Server-Programm abläuft, als Server bezeichnet.
XML: Steht für eXtensible Markup Language und ist eine standardisierte Datenbeschreibungssprache, die speziell für den Datenaustausch zwischen
Anwendungen ausgelegt ist. Hierbei handelt es sich um eine herstellerund plattformunabhängige Methode für Softwareprogramme, Daten für
andere Programme in einer verständlichen Weise zu beschreiben.
28
B
Wichtige Internetadressen
Ausgewählte RSS-Feeds:
• SPIEGEL Online:
http://www.spiegel.de/schlagzeilen/rss/0,5291,,00.xml
• Tagessschau:
http://www.tagesschau.de/xml/tagesschau-meldungen/0,,,00.xml
Weiterführende Links:
• PICS:
http://www.w3.org/PICS/
• Resource Description Framework (RDF):
http://www.w3.org/RDF/
• RFC 822 – Standard for the format of ARPA internet text messages:
http://andrew2.andrew.cmu.edu/rfc/rfc822.html
• RFC 2616 – HTTP 1.1:
http://www.w3.org/Protocols/rfc2616/rfc2616.html
• Extensible Markup Language (XML):
http://www.w3.org/TR/REC-xml
C
Abkürzungen und Akronyme
ARPA
DTD
GMT
HTML
HTTP
MCF
PICS
RDF
RFC
RSS
URI
URL
W3C
WWW
XML
XML-RPC
(heute DARPA) Defense Advanced Research Project Agency
Document Type Definition
Greenwich Mean Time
Hypertext Markup Language
Hypertext Transfer Protocol
Meta Content Framework
Platform for Internet Content Selection
Resource Description Framework
Request For Comments
Rich Site Summary, Really Simple Syndication, RDF Site Summary
Uniform Resource Identifier
Uniform Resource Locator
World Wide Web Commitee
World Wide Web
Extensible Markup Language
XML Remote Procedure Call
29
Literatur
[Ham03]
B. Hammersley: Content Syndication with RSS, O’Reilly
& Associates, Inc., Sebastopol(CA), 2003.
[HSC]
HotSheet RSS Client Software:
http://www.johnmunsch.com/projects/HotSheet/
[ORM]
O’Reilly Meerkat RSS Aggregator:
http://meerkat.oreillynet.com
[RNC]
RSS Naming Contest:
http://blog.contentious.com/contest.html
[RSS09]
RSS 0.9 Spezifikation:
http://www.purplepages.ie/RSS/netscape/rss0.90.html
[RSS091]
RSS 0.91 Spezifikation:
http://backend.userland.com/rss091
[RSS092]
RSS 0.92 Spezifikation:
http://backend.userland.com/rss092
[RSS1]
RSS 1.0 Spezifikation:
http://www.purl.org/rss/1.0/spec
[RSS2]
RSS 2.0 Spezifikation:
http://blogs.law.harvard.edu/tech/rss
30
Index
Aggregator, 16, 17, 23, 24
Userland, 4
Browser, 6, 8
Weblog, 2, 3, 17
Winer, Dave, 4, 5, 10, 17
Channel, 3, 28
Client, 22, 28
Content-Type, 3
XML, 2, 28
XML, Homepage, 29
XML-RPC, 16, 26
Dublin Core, 18
Feed, 3, 28
HotSheet, 23, 24
HTTP, 3, 8, 25, 26, 28
HTTP POST, 26
HTTP, RFC, 29
Item, 3
MCF, 2
Meerkat, 23, 24
Metadaten, 10, 16, 18, 22, 28
Modul, 18, 28
Multimedia, 16
Namespace, 4, 5, 7, 18, 21, 28
Netscape, 1, 4, 5
PICS, 11
PICS, Homepage, 29
POST, 26
Publish & Subscribe, 2, 14, 16, 25
Ramanathan, V. Guha, 2
RDF, 2, 5, 28
RDF, Homepage, 29
Ressource, 3
RSS, 28
rss-dev, 4, 5, 17
ScriptingNews, 10
Semantic Web, 2, 18
Server, 28
Taxonomie, 16
URI, 3
URL, 3
31