nicht angemeldet
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
blog