<pubDate> und <lastBuildDate>

[MightyMike]

Hallo,

ich biete auf meiner Seite seit neuestem auch einen RSS-Feed an. Dabei verwende ich - natürlich - extensiv <pubDate>. Wo genau ist aber der Unterschied zu <lastBuildDate>? Meine Interpretation:

<pubDate> - Datum der Veröffentlichung
<lastBuildDate> - Datum der letzten Änderung

Falls das so richtig sein sollte, kann ich das <lastBuildDate>-Tag auch im <item>-Element verwenden (ich habe das bisher nur im <channel>-Bereich gesehen). Wäre ganz praktisch, denn manchmal schreibe ich News, an denen ich später vielleicht noch Kleinigkeiten ändere, aber sich dabei das Veröffentlichungsdatum (<pubDate>) nicht ändert. Dies könnte man dann ja in <lastBuildDate> schreiben?!

Danke Leute
MightyMike

[wahsaga]

hi,

Falls das so richtig sein sollte, kann ich das <lastBuildDate>-Tag auch im <item>-Element verwenden (ich habe das bisher nur im <channel>-Bereich gesehen).

Nein, ich denke nicht, das gehört schon in <channel> und nur dort hin.
Es gibt an, wann du den kompletten Feed zuletzt neu generiert hast.
http://w3schools.com/rss/rss_tag_lastbuilddate.asp

Wäre ganz praktisch, denn manchmal schreibe ich News, an denen ich später vielleicht noch Kleinigkeiten ändere, aber sich dabei das Veröffentlichungsdatum (<pubDate>) nicht ändert.

Tim Tepaße hat sich mal sehr schön ausführlich zum Thema Einzelne Einträge in Feeds updaten geäußert.

gruß,
wahsaga

[Tim Tepaße]

Hallo Mike,

<pubDate> - Datum der Veröffentlichung
<lastBuildDate> - Datum der letzten Änderung

Wahsaga hat es schon gesagt:

/rss/channel/item/pubDate ist für das Veröffentlichungsdatum des einzelnen Items verantwortlich.

/rss/channel/pubDate gibt das Veröffentlichungsdatum für die Gesamtheit Items an, wenn diese keine individuellen pubDate-Informationen haben.

/rss/channel/lastBuildDate gibt das Datum an, an dem der Feed das letzte mal geändert wurde.

Um den Unterschied zu verstehen sollte man sich angucken, wobei lastBuildDate geändert werden könnte, pubDate aber nicht. So ein RSS Feed kann diverse Informationen enthalten, die nicht zum Inhalt gehören, aber trotzdem mehr oder minder wichtig sind. Eine Beschreibung des Feeds (/rss/channel/description) z.B. Oder der Verantwortliche für den Feed (/rss/channel/webMaster). Alles Informationen, die unbedingt nicht zum eigentlichen Inhalt des Feeds, den items, gehören, aber sich trotzdem ändern. Man lässt also pubDate wie es ist, ändert aber lastBuildDate um anzuzeigen, dass sich da was geändert hat.

Eselsbrücke: pubDate ist eine inhaltliche Information, lastBuildDate eine technische Information, die RSS-Reader für $irgendwas nutzen könnten, wobei niemand eine definitive Ahnung hat, was $irgendwas sein könnte.

Denn schließlich ist es eine redundante Information, zum einen ist sie schon im Prinzip in der Information Last-Modified der HTTP Header enthalten, zum anderen fetchen Aggregatoren Feeds regelmäßig, können also auch so Änderungen feststellen. Ob diese Redundanz aus einer Ignoranz von HTTP durch den letzten Autor von RSS oder durch ein eventuelles Verlangen nach einer Abstraktion vom unterliegenden Protokoll stammt, weiss man nicht.

Falls das so richtig sein sollte, kann ich das <lastBuildDate>-Tag auch im <item>-Element verwenden (ich habe das bisher nur im <channel>-Bereich gesehen).

Sprich: Nein, kannst Du nicht.

Wäre ganz praktisch, denn manchmal schreibe ich News, an denen ich später vielleicht noch Kleinigkeiten ändere, aber sich dabei das Veröffentlichungsdatum (<pubDate>) nicht ändert.

RSS 2.0 hat keinen eingebauten Mechanismus, um Timestamps von Aktualisierungen bestimmter Items zu signalisieren. In der Theorie könnte man die Elemente dc:created und dc:modified aus dem Dublin Core Metadatensatz nehmen, in der Praxis dürfte so gut wie kein Aggregator das kennen. Nicht, weil die nicht Dublin Core kennen, sondern weil diese nur eine Teilmenge von DC nehmen, die für das RSS 1.0 Dublin Core Modul spezifiziert wurde und dort sind dc:created und dc:modified nicht enthalten. Es gibt ein weiteres vorgeschlagenes Dublin Core Modul, dass alle Terme aus DC abdeckt, aber das war nie offiziell und ist sehr viel unbekannter. Nur sehr, sehr gute Feedreader kennen dieses.

Wenn Dir wirklich daran liegt, Einträge mit einem Timestamp als aktualisiert zu kennzeichnen, dann würde ich Dir einfach die Nutzung des alternativen Feedformates Atom 1.0 empfehlen. Atom ist – hat man XML-Feeds schon verstanden und das hast Du – nicht wesentlich komplexer als RSS 2.0 und vor allem hat es ein Element atom:updated schon gleich integriert. Hier ein Beispiel eines Feeds mit einem aktualisiertem Eintrag:

~~~xml <?xml version="1.0"?>
  <feed xmlns="http://www.w3.org/2005/Atom">
    <title>Beispiel-Feed</title>
    <link href="http://example.org/"/>
    <updated>2006-11-01T12:00:00+01:00</updated>
    <author>
      <name>Tim Tepaße</name>
    </author>
    <id>tag:tepasse.org,2006-11-02:selfhtml/feed</id>
    <entry>
      <title>Titel</title>
      <link href="http://example.org/1"/>
      <id>tag:tepasse.org,2006-11-02:selfhtml/feed/1</id>
      <updated>2006-11-01T12:00:00+01:00</updated>
      <published>2006-11-01T11:45:00+01:00</published>
      <summary>Aktualisierte Zusammenfassung</summary>
    </entry>
  </feed>

  
`/feed/updated`{:.language-xpath} kann hier die Entsprechung von lastBuildDate sein, wobei die Atom-Entsprechung redaktionell gepflegt sein kann.  
  
`/feed/item/published`{:.language-xpath} ist das Datum, an dem ein Eintrag im Feed das erste Mal publiziert wurde.  
  
`/feed/item/updated`{:.language-xpath} ist das Datum, an dem ein Eintrag im Feed das letzte Mal signifikant geändert wurde. Es bleibt dem Autor überlassen, dieses Datum zu ändern, wenn man einfach nur einen kleinen Rechtschreibfehler verbessert, muss es also nicht zwangsläufig geändert werden und der so minimal geänderte Eintrag muss also nicht zwangsläufig als ungelesen im Feedreader erscheinen.  
  
Du merkst, so sehr anders als RSS 2.0 ist Atom 1.0 gar nicht. Die Elemente heissen teilweise anders, es gibt in einigen Bereichen mehr Elemente, das Format des Datums ist anders (ISO Standard) und es gibt diese verpflichtenden IDs. Warum die nützlich und praktisch sind, dazu habe ich schon einiges im von Wahsaga verlinkten Posting geschrieben.  
  
  
Tim