RSS / Atom

[tone]

Hallo,

mir ist der Vorteil von Atom bzw. der Nachteil von RSS nicht ganz klar.
Ich will eine Datenbank für Oldtimer erstellen, dafür hätte ich gerne einen Feed, der mir die 15 zuletzt eingetragenen Modelle anzeigt. Das hab ich jetzt auch mit RSS 2.0 gemacht (wobei für mich hier kein Unterschied zu 0.91 besteht): title, link, description und meine 15 dynamischen items mit gleichem. Bin eigentlich soweit zufrieden.....würde ich etwas verpassen, wenn ich bei RSS bliebe und nicht zu Atom wechsele? Was ist in euren Augen DAS Feature von Atom, was RSS nicht besitzt. Das ganze ist eine Aufgabe für die Uni, wäre es unter dem Umstand nicht auch besser zum neueren Atom zu wechseln?

Danke für die Hilfe.

[Pit]

Ist Atom closed-source? Dann bleib bei RSS =)

[Tim Tepaße]

Hallo Pit,

Ist Atom closed-source? Dann bleib bei RSS =)

Ist es nicht. Tatsächlich ist Atom ein RFC der allgemein akzeptierten Internet Engineering Task Force (IETF) mit über zwei Jahren Entwicklungszeit, während das Copyright der Spezifikation von RSS in der Version 2.0 von der Universität Harvard getragen wird, die ausdrücklich nicht wünscht, diese Spezifikation zu verbessern, RSS in der Version 1.0 ist letztendlich nur ein Dokument, das vor Ewigkeiten von einer Gruppe auf einer Mailingliste zusammengestellt wurde – und seitdem im Netz steht.

Für Endnutzer und nicht besonders an Formatdetails interessierte Entwickler ist der Unterschied aber marginal, ja.

Tim

[Thomas J.S.]

Hallo,

Ist Atom closed-source? Dann bleib bei RSS =)

Ist es nicht. [...]während das Copyright der Spezifikation von RSS in der Version 2.0 von der Universität Harvard getragen wird,

Copyright schon, aber der Lizenz ist etwas anderes:

"RSS 2.0 is offered by the Berkman Center for Internet & Society at Harvard Law School under the terms of the Attribution/Share Alike Creative Commons license. The author of this document is Dave Winer, founder of UserLand software, and fellow at Berkman Center."
http://creativecommons.org/licenses/by-sa/1.0/

die ausdrücklich nicht wünscht, diese Spezifikation zu verbessern,

Das hat auch seine Gründe und ich finde die gar nicht schlecht:
http://blogs.law.harvard.edu/tech/rss#roadmap

Grüße
Thomas

[Tim Tepaße]

Hallo Thomas,

die ausdrücklich nicht wünscht, diese Spezifikation zu verbessern,
Das hat auch seine Gründe und ich finde die gar nicht schlecht:
http://blogs.law.harvard.edu/tech/rss#roadmap

Dort steht aber auch:

„We anticipate possible 2.0.2 or 2.0.3 versions, etc. only for the purpose of
  clarifying the specification, not for adding new features to the format.“

Also genau das was RSS 2.0 braucht, was aber nie passierte. Zur Erinnerung: Gemeinsam mit der Übertragung des Copyrights von RSS 2.0 von Userland Software im Rahmen von Dave Winers Fellowship dort wurde auch das RSS Advisary Board gegründet, zu dessen Aufgaben es auch gehörte, „minor changes to the spec per the roadmap“, im wesentlichen also „clarifications“. Einen Hauch geschah das ja auch. Big Dog™ Dave Winer trat dann 2004 zurück, nachdem er meinte, dass die existierenden Mitglieder des Boards den „Prozess der Klarifizierung der Spezifikation“ genügend verstanden hätten. Klarstellungen und Fehlerbeseitigungen sind also durchaus beabsichtigt. Leider wurden diverse Punkte niemals adressiert, auch wenn sie in der Blogosphäre von Entwicklern und sonstigen Interessierten rund um RSS immer wieder gefragt wurden. Ein paar Beispiele:

• Sind relative URIs in RSS-Feeds erlaubt? Wenn ja – denn das ist durchaus üblich, ein Aggregator muss sich darauf einstellen – nach welcher Basis-URI werden diese aufgelöst? Der URI, von der der Feed runtergeladen wurde? Nach der URI von /rss/channel/link? Nach der URI von //item/link? Nach der URI von //item/guid/@isPermaLink="true"? Was gilt für relative URIs in maskiertem HTML von //item/description?

• Wie ist der Inhalt von //item/title zu interpretieren? Als HTML oder als reier Text? Die Spezifikation erwähnt die Möglichkeit des Maskierens von HTML nur für //item/description, trotzdem ist es seit Jahren gewachsene Tradition title wie description zu behandeln, vermutlich weil die Software Radio Userland es so tut „und die ist ja schließlich von Dave Winer“.

• Woher weiss ein Aggregator in einem RSS 2.0-Feed, dass ein description-Element nun maskiertes HTML oder reiner Text ist und wie er die Bytes behandeln soll?

• RSS 2.0 enthält diverse sich aufs Caching und Fetching auswirkende Elemente wie <ttl>, <skipDays> und <skipHours> – wie interagieren diese mit HTTP?

• Die in <skipHours> angegebenen zu überspringenden Stunden sind explizit in GMT angegeben. Wenn der Aggregator nun in Australien sitzt und auf einen Feed mit <skipDays><day>Sunday</day></skipDays> stolpert – in welchen Zeitraum soll er nun den Feed nicht runterladen? Den Sonntag nach GMT-Zeit oder den Sonntag nach australischer Zeit? Mal abgesehen davon, dass kein vernünftiger Aggregator sich eh nicht daran halten würde.

• Sind nur URIs („URLs“ nach der Spezifikation) erlaubt oder kann ich einfach IRIs zum Beispiel bei IDNs in den Feed rein schreiben?

• Nach welchen Prinzipien sollen GUIDs verglichen werden, die auch Permalinks sind: nach reinen String-Vergleichen oder URI-normalisiert?

• Wieviele Enclosures dürfen in einem Eintrag im Feed enthalten sein? Die Spezifikation macht keine Aussage, konsequenterweise gibt es Software, die mehrere Enclosures verarbeitet, aber auch Software, die nur eines annimmt, entweder das erste angeführte oder das letzte. Ah ja.

undsoweiter ..

Fast-Forward zu Ende 2005, Anfang 2006:

Roger Cadenhead, der Vorsitzende des RSS Advisory Board bringt nach Diskussion mit seinem Mitbrettlern wieder etwas Leben ins Spiel. Es wird eine neue Domain registriert, dort im Gegensatz zur Harvard-Infrastruktur auch alte Revisionen der Spezifikation publiziert, eine öffentliche Mailingliste eingerichtet – und ein neuer Draft von RSS veröffentlicht. Wohlgemerkt: Kein vollkommen neuer Entwurf mit neuen Elementen oder sonstigen Weiterentwicklungen sollte es werden, es sollte vor allem eine Umschreibung  des derzeitigen Sprachbestands in eine klarere und rigidere Sprache sein. Sprich: Definitionen von Datentypen, richtige Definitionen. Und ja, auch ein paar Klarstellungen. Man glaubte sich im Sinne der Roadmap zu befinden.

Drei Wochen lang ging es auf der Mailingliste durchaus relativ gut voran. Viele Punkte wurden angesprochen und durchaus diskutiert. Einige der alten Gutwilligen, die sich 2003 enttäuscht Atom zugewendet haben tauchen noch mal auf und bringen Fachkenntnis mit. Nur scheint das plötzlich Herrn Winer, der zwei Jahre vorher vom RSS Advisory Board zurück getreten ist, nicht zu behagen, er regt sich auf, sieht komische Verschwörungen und „beendet das Experiment“, in einem Board, dem er nicht mehr angehört, das über Klarstellungen in einer Spezifikation debattiert, deren Copyright er an jemanden anderes übertragen hat.

Wichtiger ist dieses Statement von John Palfrey, im wesentlichen lautet es: „Toll, dass ihr was macht, wir wollen damit nix zu tun haben, unsere Spezifikation ändert sich nicht.“ Oder wie es Dave Winer ausdrückt:

1. The spec is owned by Harvard.
  2. The RSS Advisory Board, when it existed, performed a support function.
     Later, in case anyone was still confused, we disclaimed: "It does not own
     RSS, or the spec, it has no more or less authority than any other group of
     people who wish to promote RSS."

Danach hat er sich aufgemacht, seinen ehemaligen guten Freund Roger Cadenhead zu verklagen – aber wenigstens wegen was anderem.

Das fleissige RSS Advisory Board existiert also nicht und darf also auch nix klar stellen. Das ist der Endstand in der Hinsicht auf eine klarstellende Veränderung der RSS-Spezifikation, eine Art normatives Errata.

RSS 2.0 ist eingefroren. Es wird keine Weiterentwicklung, es wird nicht mal Errata geben. Es wird kein RSS 3.0 geben, Harvard will das nicht, Dave Winer hat kein Interesse, jeder andere, der das machen will hat laut Roadmap keine Chance, weil er das dann nicht RSS nennen darf. Das RSS Advisory Board darf es nicht, weil es nicht existiert. RSS 2.0 ist eingefroren. Ein netter Trick.

Was sich da aber herauskristallisiert hat: Man kann Best Practice Dokumente schreiben. So ziemlich jeder, Dave Winers tut es, Nick Bradbury von Newsgator tut es, Das RSS Advisory Board tut es, Alex Shields von Textpattern tut es, Andy Seidl von wasauchimmer tut es. Wenn ich mal Langeweile habe, schreibe ich auch mal schnell so ein Ding.

Natürlich ist auch Dave Winers andere Seite halbwegs verständlich, er will nicht, dass die Spezifikation zum Spielball unterschiedlicher Marktinteressen wird. Er fürchtet eine Balkanisierung. So kommt es dann dazu, dass er plötzlich andere am Format interessierte Entwickler anderer Firmen als Gefahr denn als Chance sieht bis hin zu absurden Attacken. Aber dass er eine schwierige Persönlichkeit hat, ist ja schon bekannt.

Aber das er es offenbar nicht schafft über den Zeitraum von über vier Jahren zu erkennen, dass es den Kritikern nicht um Balkanisierung sondern um Beseitigung von Schwächen im Kern ging, verblüfft mich noch immer. Er sagt selber, dass es alles andere als perfekt oder gar gut ist. Offenbar ist ihm das Einfrieren lieber als eine Verbesserung. Oder auch nur ein Errata.

Shelley Powers hat die Haltung schön beschrieben:

„The current custodian of the RSS 2.0 copyright, Harvard, takes a passive view
  of the specification–seemingly willing to have the authority over the
  specification, without accepting any responsibility for its care.“

Tim

[Thomas J.S.]

Hallo Tim,

Auch wenn ich deine Vorliebe für ATOM kenne ;-), danke dir für das Zusammensuchen der Informationen. Ich habe auch eine Weile verfolgt, was Dave Winer veranstaltet hat.
Aber was wirklich hinter der ganze Sache steckt, werden wir wohl nie erfahren. Ob er "eingeschnappt" ist oder ob ihm das ganze Tohuwabohu um RSS irgendwann einfach nur noch auf die Nerven ging?

Ich kann die Haltung von Harward (möglicherweise) verstehen, wenn sie nicht wollen, dass RSS unter zu vielen verschiedenen Interessen "aufgerieben" wird und deshalb einstweilen - denn was die Zukunft wirklich bringt, wissen wir nicht - die Spez. eingefroren haben.

Grüße
Thomas

[Ashura]

Hallo tone.

mir ist der Vorteil von Atom bzw. der Nachteil von RSS nicht ganz klar.

Auch wenn er momentan offenbar nicht anwesend ist, solltest du im Archiv einmal nach Postings von Tim Tepaße zu diesem Thema suchen. Danach dürftest du am ehesten einen Überblick haben und kannst vielleicht schon eine Entscheidung treffen.

Einen schönen Donnerstag noch.

Gruß, Ashura

[tone]

Danke an alle für die Antworten.

Habs jetzt einfach in Atom umgeschrieben, alleine aus Gründen der Aktualitat.

Womit ich jetzt allerdings auch schon bei meinem ersten Problem wäre und zwar

<content type="html" >
  <img src="http://localhost:8080/test.jpg" style="max-width:150px; max-height:150px;"></img>
        <p><xsl:value-of select="substring-before($beschreibung,substring-after(substring-after($beschreibung, substring($beschreibung,1,200)), '.'))" />
         </p>
</content>

zeigt er mir hier leider nicht das Bild an. Setze ich <content type="xhtml" > zeigt er mir alles an.
Es ist nur leider so, dass ich den nachfolgenden Text (alles innerhalb von <p>) aus einem xml File nehme, welches <br> Tags besitzt, die unter XHTML auch als <br> ausgegeben werden und nicht als Zeilenumbruch dargestellt werden, wie es unter <content type="html" > der Fall ist. Wie könnte ich das umgehen?

Vielen Dank.

[tone]

Hat sich erledigt...
.

[Tim Tepaße]

Hallo tone,

Danke an alle für die Antworten.

Tschuldige, dass ich erst jetzt auf Dich eingehe, ich wurde aufgehalten ;)

Habs jetzt einfach in Atom umgeschrieben, alleine aus Gründen der Aktualitat.

Das wollte ich Dir auch raten. Im wesentlichen ist meine Argumentation ebenso einfach: RSS hat ein paar Unwägbarkeiten, von denen ich ein paar in der Antwort an Thomas erwähne, Atom kann alles, was RSS kann und noch mehr, Atom hat weniger Unwägbarkeiten. Der Support für Atom in den großen und verbreiteten Feedreadern ist derzeit recht akzeptabel, in einem halben Jahr denke ich, dass Support für Atom sich durchgesetzt hat.

Sprich: Es gibt als Anbieter keinen Grund mehr RSS zu benutzen, wenn man Atom anbieten kann und will.

Auch wenn es sich schon erledigt hat, hier noch mal Hinweise dazu:

<content type="html" >
  <img src="http://localhost:8080/test.jpg" style="max-width:150px; max-height:150px;"></img>

Die Vorschrift von Atom für type="html" ist klar:

1. Man kann nicht einfach irgendwelche Kindelemente reinhauen.
2. Man muss HTML-Inhalt maskieren, d.h. alle "<", "&" und eventuell noch ">" durch die jeweiligen Entities ersetzen, das sind "&lt;", "&amp;" und "&gt;".

Dafür weiss der jeweilige Deinen Feed verarbeitende Prozessor: „Aha, das ist HTML, hier muss ich die Entities durch ihre richtigen Zeichen ersetzen und den sich ergebenden String wieder als HTML behandeln.“ ohne wie bei RSS raten zu müssen ob das nun Text oder HTML ist.

zeigt er mir hier leider nicht das Bild an. Setze ich <content type="xhtml" > zeigt er mir alles an.

Wobei Du da streng genommen einen Bug ausnutzt. Die Vorschrift für type="xhtml" sagt:

1. Es darf nur XHTML enthalten sein.
2. Das enthaltende XHTML muss sich zusätzlich in einem eigenen Div-Element befinden, das ist bei Dir nicht so.
3. Das enthaltende XHTML muss sich im XML-Namensraum von XHTML befinden, bei Dir scheinen die Elemente aber im XML Namensraum von Atom.

Richtiger wäre es so:

<content type="xhtml">  
  <div xmlns:xhtml="http://www.w3.org/1999/xhtml"  
    <img src="http://localhost:8080/test.jpg" style="..." />  
  </div>  
</content>

Es ist nur leider so, dass ich den nachfolgenden Text (alles innerhalb von <p>) aus einem xml File nehme, welches <br> Tags besitzt, die unter XHTML auch als <br> ausgegeben werden und nicht als Zeilenumbruch dargestellt werden, wie es unter <content type="html" > der Fall ist. Wie könnte ich das umgehen?

Vermutlich wusste Dein Tool noch nicht mal, dass damit XHTML-<br>s gemeint waren. Allein "<br>" ist ja noch nicht mal richtiges XHTML. Bei type="xhtml" muss aber nicht nur Atom wohlgeformt nach XML und valide sein, auch das in Atom enthaltene XHTML muss wohlgeformt nach XML und sollte valide sein. "<br>-Tags" sind schon mal nicht wohlgeformt. Streng genommen dürfte dann auch Deine Ursprungs-XML-Datei nicht wohlgeformt sein, interessant, dass Du diese offenbar mit XSLT verarbeiten kannst.

Aber es scheint ja jetzt zu klappen.

Trotzdem: immer, wenn Du einen Feed – ob nun im Format RSS oder Atom – entwickelst, solltest Du diesen im Feedvalidator auf Gültigkeit überprüfen lassen. Und frag ruhig hier.

Tim

[tone]

Hi Tim,
na das nenn ich mal eine Antwort...vielen Dank für die Mühe.
Wie du richtigerweise geschrieben hast, lag es an der Maskierung.

Wieso das XML trotz <br> wohlgeformt ist? Ich ziehe die Daten mittels Cocoon SQL Transformer aus einer DB. Den Inhalt interpretiert er allerdings in diesem Schritt noch nicht, d.h. <br> geht als ein Zeichenkette durch wie jede andere auch.

Nochmals danke für die präzise Auskunft.