Erweiterungsmodule

(Auszug aus "Newsfeeds mit RSS und Atom" von Heinz Wittenbrink, erschienen bei Galileo Press, 2005)

Im Gegensatz zu seinen Vorgängern aus der RSS 0.9x-Familie lässt sich RSS 2.0 durch Module erweitern. Ein Modul besteht aus XML-Elementen, mit denen zusätzliche Funktionen realisiert werden können. Die Elemente eines Moduls müssen zu einem eigenen definierten XML-Namensraum gehören.

Mit dem Namensraum-Mechanismus verwendet RSS 2.0 eine Technik, die schon früh eingeführt wurde, um XML-Vokabulare zu erweitern. Wenn Ihnen diese Technik nicht geläufig ist, können Sie sich unter XML-Namensräume so weit über sie informieren, wie es zum Weiterlesen erforderlich ist.

Modularisierung und Erweiterbarkeit kennzeichnen auch die beiden anderen Syndikationsvokabulare: RSS 1.0 und Atom. Grundsätzlich lassen sich Module, die zusammen mit RSS 2.0 verwendet werden, auch mit diesen Vokabularen kombinieren. Allerdings gelten bei RSS 1.0 und Atom zusätzliche Einschränkungen, die RSS 2.0 nicht kennt.

Offene Fragen zur Erweiterbarkeit

Die Frage, wie Erweiterungen von XML-Vokabularen interpretiert werden sollen, wird Ihnen auf den folgenden Seiten wiederbegegnen. Man könnte sie etwa so formulieren: Lassen sich für Erweiterungen generelle Mechanismen festlegen oder muss für jede Erweiterung eines Formats einzeln definiert werden, wie eine Zielanwendung die neuen Elemente verarbeiten soll? Die Diskussionen über RSS 1.0 und Atom machen die Probleme sichtbar, die mit den Erweiterungen eines Syndikationsvokabulars verbunden sind.

Hier reicht es festzuhalten, dass vielen Entwicklern anderer Syndikationsstandards der Namensraum-Mechanismus allein nicht genügt, um festzulegen, wie ein RSS-Vokabular erweitert werden kann.

Alle Nicht-RSS-Elemente gehören in einen Namensraum

Ein RSS 2.0-Feed darf Elemente aus anderen Vokabularen nur enthalten, wenn sie zu einem definierten Namensraum gehören. Weitere Einschränkungen für Erweiterungen bestehen nicht. Sinnvoll sind Erweiterungen allerdings nur, wenn es Software gibt, die die zusätzlichen Sprachelemente verarbeiten kann.

Meist kennzeichnet ein Präfix, das durch einen Doppelpunkt vom lokalen Namen abgetrennt ist, die Elementnamen, die aus einem Erweiterungsmodul stammen. Beispiele dafür sind ssr:rdf oder dc:author. Software, die mit ihnen nichts anfangen kann, darf diese Elemente einfach ignorieren. Zu welchem Namensraum diese Elemente gehören, teilt dem Prozessor die Namensraum-Deklaration mit.

Der Prozessor ordnet Attribute, die kein Präfix haben, dem Namensraum des Elements zu, bei dem sie stehen. Attribute mit einem Präfix lassen sich auch mit Elementen aus anderen Namensräumen kombinieren.

Kein Namensraum für die RSS-Elemente selbst

Die RSS-Elemente selbst werden keinem Namensraum zugeordnet. Bei einer Verwendung von Namensräumen wäre die Kompatibilität zu den Vorgängerformaten nicht gewahrt. Wäre zur Validierung eines RSS-Dokuments die Erklärung eines Namensraums erforderlich, dann wären RSS 0.91- und 0.92-Dokumente zwangsläufig nicht valide. Allerdings hat Winer selbst später vorgeschlagen, mit einem Namensraum für die Elemente des RSS-Vokabulars zu experimentieren – letztlich aber ohne Ergebnis.

Risiken für die Struktur

Namensräume werden auch von den anderen Syndikationsformaten für Erweiterungen benutzt – allerdings in einer Weise, die eingeschränkter und expliziter als bei RSS 2.0 ist. Winer sagt in der RSS 2.0-Spezifikation nichts darüber, an welchen Stellen in einem RSS-Dokument Erweiterungen erlaubt sind. Andere Autoren wie Morbus Iff (aka Kevin Hemenway) haben darauf hingewiesen, dass Erweiterungselemente, die nicht Nachkommen von channel oder item sind, die Struktur eines RSS-Dokuments verändern und dazu führen können, dass die Dokumente fehlerhaft verarbeitet werden (siehe Extending RSS 2.0 With Namespaces).

Bei Erweiterungen gilt: less is more

Dave Winer hat immer wieder empfohlen, Namensräume nur sparsam zu verwenden. Vor allem wandte er sich dagegen, Erweiterungen da zu verwenden, wo RSS 2.0-Elemente ausreichen (eine Praxis, die er als funky bezeichnet.) Oberstes Interesse ist auch hier Einfachheit des Formats für den Benutzer und Einfachheit für den Implementierer. RSS leistet viel, weil es ein Standard ist. Erweiterungen, die sich nicht breit durchsetzen, sind sinnlos – mit der Ausnahme von Erweiterungen, die für eine genau definierte Software entwickelt wurden. Auch hier gilt: Less is more. Module mit wenigen, einfach und eindeutig definierten Elementen sind am leichtesten zu implementieren und haben die größte Chance, sich breiter durchzusetzen. Wer selbst Namensraum-URIs definiert, sollte darauf achten, dass sie mit einem Slash / oder Doppelkreuz # enden. RDF-Anwendungen können solche URIs leichter verwenden, um Elementnamen als eindeutige Identifizierer von Eigenschaften zu interpretieren (siehe die Passagen über die URIs von Prädikaten unter RDF-Grundlagen).

   

   

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Newsfeeds mit RSS und Atom bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: