A Guide to RSS Elements: Beyond Title, Description, and Link Copyright 2006 - Greg Smith; Elegant Computer Design [Updated  April 6, 2006 to relfect recent changes to commentRss] You’ve got your RSS feed up and running and you already have the <title>, <description>, and (maybe) <link> elements in your feed. And now you want to optimize your feed for FeederReader or other offline aggregators? This guide will help you understand what RSS elements you can add to your feed to optimize the user experience in FeederReader and, likely, other aggregators. <pubDate> pubDate will tell the aggregator exactly when the item was published. Otherwise, the only hint that the aggregator has is the time the feed is updated. In many cases, the user can look at the download time and get a general clue about when the item was published because the user is updating anywhere from hourly to weekly. But when the user first pulls down your feed and you don’t have a pubDate, all items will be marked as published at the download time. If you have any items that were published, for instance, five weeks ago, then the user has to mentally sift through items to determine when they might have been published (or be left to wonder). Additionally, the user can list items from multiple feeds in chronological order. If you have individual pubDate elements, then your items will be listed correctly among other feeds instead of lumped into groups of items downloaded at the same time. Be careful of the correct format of the pubDate element and be careful of outputting the correct time/timezone relative to Daylight Savings Time (aka “Summer Time”). It is probably safer to automatically generate UTC times rather than using “PST” or “PDT” (which you would likely have to change back or forth every 6 months). <dc:creator> http://dublincore.org/ (there isn’t a clear concise description of dc:creator in an RSS feed) dc:creator is the name of the person or group that created the item. This should be just a simple “First Last” name or a (relatively short) group name. The dc:creator (for display purposes) is useful even when you have an <author> element (http://blogs.law.harvard. edu/tech/rss#ltauthorgtSubelementOfLtitemgt ) because the <author> element is specified to be the email address of the author, while <dc: creator> is simple display text. <title> of the RSS channel http://blogs.law.harvard.edu/tech/rss#requiredChannelElements It is important that the title of the RSS channel be relatively short and displayable (no markup) and yet specific enough to differentiate from any other of your feeds. For instance, if you have multiple video feeds with different enclosure types, then the titles of your RSS channels should indicate “Cool Videos WMV” or “Cool Videos MOV”. Or if you have a text-only feed, a audio only feed, and a mixed feed “Great Greg Info - text only”, “Greg Greg Info - audio only”, “Great Greg Info - text and audio”. <image> of the RSS channel http://blogs.law.harvard.edu/tech/rss#ltimagegtSubelementOfLtchannelgt The image of the RSS channel is (optionally) displayed at the top of every message. It is scaled to be displayed at a maximum of  30 pixels high and the width of the device (generally around 230 pixels). It is best that your image be horizontally oriented, possibly with your logo and the name of your feed or organization within the image. The <pubDate>, <dc:creator>, <title> and <image> elements all work together to present a useful item display to the user. The display consists of the image on top, followed by the title (as a link using the <link> element), followed by a byline that reads “ – 1 hr ago by Greg Smith from Cool Videos”). <guid> http://blogs.law.harvard.edu/tech/rss#ltguidgtSubelementOfLtitemgt This “Global Unique Identifier” allows you to republish or update specific items without duplicating these items in an aggregator. If you change an item without using the <guid> element, then the aggregator has no way of determining that the new item is replacing an old item. In that case, the aggregator will retain the old item and the new item, forcing the user to read it twice. If the <guid> element exists (and is the same as a previous item’s <guid>) then the aggregator can (at the users option) replace the old item with the new one. If the user has not read the item yet, then all they will see is the updated item. If they have read the old item already, then they can optionally read the update or ignore it. <source> http://blogs.law.harvard.edu/tech/rss#ltsourcegtSubelementOfLtitemgt This is the URI of the RSS feed from which you got a particular item. When the <source> element exists in an item, the user is presented with an easy way to subscribe to this link. This would also be an alternative way (to OPML) to present a list of feeds that a user can optionally subscribe to. If you have a list of 5-30 feeds that you want to recommend to a user, you could create an RSS feed that contains those feeds including a title, description, and source elements. The user could then scan the list of titles to see which might be interesting, and subscribe easily to each one that is interesting. <comments> http://blogs.law.harvard.edu/tech/rss#ltcommentsgtSubelementOfLtitemgt comments is specified to be the URL of the web page that contains comments and an HTML form that allows comments to be posted. For offline aggregators (users reading your RSS feed while disconnected from the Web), this is a big problem. If a user is not connected to the web, they cannot comment on any items in your feed. If they wanted to (and remembered to), they could wait until they got an internet connection, then go back to your item, and select the comments page to view and/or post. How likely is that? A much better way to support comments is to implement the CommentAPI. CommentAPI - <wfw:comment> http://wellformedweb.org/story/9 If your server supports the CommentAPI, you can publish the <wfw: comment> element with your item. This allows offline aggregators to present a standard form, collect the user’s comment, and save the comment until the next time the user connects to the internet. Comment RSS Feed - <wfw:commentRss> Use of <wfw:commentRSS> (note capitalization difference) is Deprecated: This contains the URI of the RSS feed that contains the comments for this item. This URI can be presented to the user while reading the item and, if interested, the user can subscribe to the comments in this feed to be notified of and be able to read (offline, if desired) any comments on this item. History of wfw:commentRss vs. wfw:commentRSS. In April of 2006, Joe Gregorio mentioned on the Feed Validator list that he changed the well-formed web link describing this element from wfw: commentRSS to wfw:commentRss because it had conflicted with Chris Sells' published specification. Due to this change, feed producers are recommended to use the following capitalization: <wfw:commentRss>. [Deprecated April 6, 2006] Here are my original comments regarding the wfw:commentRss element. http://www.sellsbrothers.com/spout/default.aspx?content=archive. htm#exposingRssComments (If this link doesn’t work, see the Appendix) ... Unfortunately, the link within the “Well Formed Web” page lists this element as “wfw:commentRSS” and the Chris Sells Specification lists this element as “wfw:commentRss”. (see http://trac.wordpress.org/ticket/1544 -- or Appendix B -- for a great explanation why wfw:commentRSS seems “correct”).