Wer schon einmal einen RSS-Reader oder ein RSS-Widget entwickelt hat, der weiß welches unstandardisierte Wirrwarr heutzutage aus Contentmanagementsystemen heraus exportiert und trotzdem als RSS bezeichnet wird. Zudem wird beim Export der Feeds auch nur an einen einzigen Anwendugnsfall gedacht – nämlich den RSS-Reader auf HTML Basis – und nicht an die universelle Verwendbarkeit des Formats im gesamten Long Tail.
a) CDATA
Bestes Beispiel dafür ist die Verwendung von CDATA-Formatierungen. Mit dieser Technik können HTML-Formatierungen in den RSS-Feed aufgenommen werden. Beispiele:
Diese eigentlich positiven Erweiterungen stellen allerdings auch zum Teil Vergewaltigungen des Feeds dar. Was z.B. für einen Browser noch spannend erscheint ist für ein Widget oder einen nicht browser-basierten RSS-Reader schon eine echte Herausforderung: Hier müssen die Formatierungen zum Teil mühsam herausgefiltert werden.
Wie der Long Tail zeigt, gibt es unzählige Möglichkeiten, um nützliche oder einfach nur coole Tools mit RSS zu füttern. Eine technische Basis dafür ist z.B. die Verwendung von Adobe Flash, Microsoft Gadget Builder oder Apple Script. Nur: Die damit erstellten Tools benötigen einen im Einzelfall recht komplizierten Parser – vor allem, um die RSS-Feeds von all dem Unrat zu befreien, der ausschließlich für HTML-Reader nützlich ist. Dies gilt insbesondere für die in manchem Feed eingebundenen Tag-Listen, die direkt in die Content-Summary integriert werden.
Da sich RSS-Feeds für browserbasierte Anwendungen gut mit CSS verbinden lassen, besteht grundsätzlich kaum die Notwendigkeit CDATA-Formatierungen zu verwenden. Schließlich werden CDATA-formatierte RSS-Feeds auch deutlich schwerer (haben also mehr Kilobytes) und ihre Verarbeitung z.B. durch Flash erfolgt meist wahrnehmbar verzögert (geringere Performance, da zusätzliches Parsen nötig ist).
RSS-Feed als Quelltext. Der Idealfall für die universelle Verwendung im Long Tail: Einfache Feeds ohne CDATA-Formatierungen.
b) Formatwahl / Standard
RSS verfügt (leider) über mehrere verschiedene Standards. Diese Formate werden jedoch in vielen Fällen nicht standardkonform umgesetzt.
Geht es über Headline und Summary hinaus, werden also z.B. Bilder, Videos und/oder Audios eingebunden, beginnt ein geradezu krimineller Wildwuchs, der jeden Entwickler eines RSS-Tools verzweifeln lassen kann:
Die Anzahl möglicher und unmöglicher Fehler, die hier gemacht werden können ist unbegrenzt – und das, obwohl es unzählige Websites gibt, die den RSS-Standard gut dokumentieren. Anbei drei von vielen Seiten zu RSS-Standards im Netz:
- www.oreillynet.com/rss
- www.zdnet.de
- search.yahoo.com/mrss
Natürlich kommt erschwerend hinzu, dass Mac, Microsoft, Yahoo und Google als Big-Player in diesem Geschäft jeweils eigene Dialekte bevorzugen. Aber das sollte kein Grund für RSS-Anbieter sein, diese bekannten Standards falsch umzusetzen oder gar neue – ganz und gar undurchsichtige – Formate dazu zu entwickeln.
c) Encoding
Scheinbar nur eine Frage für Rabulisten ist: Soll man UTF oder ISO Encoding verwenden? Denkt man an den Long-Tail und nicht allein an die singuläre Nutzung in HTML-gestützten Readern, empfiehlt sich unbedingt das UTF-Format.
Doch egal für welches Format man sich entscheidet: Das sollte dann auch einheitlich verwendet werden. Anders mancher Anbieter, der jeden Feed in einem anderen Format und auch innerhalb eines Feeds für Headlines und Summaries abweichende Fonts verwendet.
Schließlich sollte die Encoding-Bezeichnung im Header des Feed wirklich mit dem Encoding-Format übereinstimmen, das verwendet wird.
Je weniger Formatierung man in einen RSS-Feed aufnimmt, desto universeller ist dieser später im Long Tail einsetzbar. Jedem Anbieter sei empfohlen, die Notwendigkeit und den Umfang von CDATA-Formatierungen genau zu prüfen: Je klassischer ein RSS-Feed geformt ist, desto besser für den Long Tail.
Weiterführende Links
- RSS – der Standard für Inhalte im WEB 2.0
- RSS-basiertes WEB-TV und IPTV
Bitte beachten Sie unsere Informationen zum Datenschutz.
blog comments powered by Disqus© 2012 FEiG & PARTNER