intertwingly

Sam: In my case, the original post will always be in the comment feed. If for no other reason than the fact that any given "original post" may just be another comment within someone else's thread.

I'd say the item should NOT be duplicated, and the comment feed should initially contain no items.  And then we would, of course, modify the validator to allow no-item feeds...

Zero item feeds do, or at least used to cause problems for Aggie, but I consider that a bug, so zero items is okay.

I like the original item in the channel.description, when I went to implement this in Bulu I looked at your feed and liked what you had done and copied it.

The whole situation does point to a striking symmetry in RSS that really isn't supported by the current element naming conventions. That is, the major elements of channel (title, link, description) are the same as the major elements of item (title, link, description).

Arrgh, (beats head against language trying to make a lucid point.) Will post blog entry that tries to explain this.

I personally see no reason to duplicate the blog post as an item in the comments feed.  As the channel title/description/link, yes, but as an item, no.

I'd personally prefer if the first blog post was not placed in the feed. In fact, I can't think of any reason for the original post to exist in the comments feed.

Phil: Are implementors likely to be cunning enough to strip off an item in a commentRSS feed that duplicates the item where they got the URL?

That is expecting them to be very cunning indeed.  Looking at Sam's comment feed I find no way to programmatically distinguish a comment from the original post, except their order in the file. (and RSS 2.0 doesn't even have explicit ordering!) 

But give the implementors something (anything) to filter on, and I except they'll rise to the challenge.  The annotation module always seemed like a good choice to me.

Also, Joe, historically RSS (at least RSS 1.0) has required there to be a minimum of one item per channel, even if the item was empty.  I think the general feeling is this is an out dated idea, but it is still part of the spec.  So I wouldn't say its Aggie's bug alone :)

kellan,
I don't see why there should be any difficulty in removing the duplicate comment from the comment's feed. As long as the  or <guid ispermalink="true"/> elements are the same then it is a no-brainer. It's just extra work I'd rather not do.

I can't think of any reason for the original post to exist in the comments feed.

The "original post" isn't necessarily a meaningful concept.

If I post an entry on a new topic to my Coldfusion tips blog, for example, that entry could be considered the original post for the resulting comment feed. But if someone else comments on my entry and makes his comment an entry in his own blog, that single feed will now contain two "originals".

If you get to the comment feed via my blog feed, then stripping out my post might be fine. But if you get to it via Person B's blog feed, stripping out my post won't have the intended effect.

Granted, none of that applies to apps that draw bright lines between "entries" and "comments", so this isn't intended to sway anyone else's implementation. It just explains mine.

Dare:

Agreed GUIDs would make it a simple task for certain types of backends.  A few caveats.

Sam's feed doesn't have GUIDs in it, hence my statement, "looking at Sam's comment feed I find no way to programmatically distinguish a comment from the original post", is still true. (in an RSS 1.0 feed you might be able to use the rdf:about attribute of an item, though thats not guarenteed to be globally unique)

Also you are positing a relatively intelligent aggregator with some sort of persistent memory as an essential part of the equation, but wouldn't it be nicer if that information was store within the feed, rather then having to infer it from external knowledge?

Its not like the annotation module is any more complicated then the guid tags.

Is a feed with zero items really a violation of the spec ? If so, the spec should probably be updated, because that restriction really makes no sense.

Including the post as an item seems just clumsy and is an ugly work around, imho.

The DTD for 0.91 says "item+".  RSS 1.0 says "Requirement: >= 1".  RSS 2.0 says "A channel may contain any number of <item>s."

FWIW, there are a number of feeds in the wild (many of the sourceforge feeds, for example) that don't have any items.  IMHO, we should change the specs to allow this...

Determining the entry programmatically: if all you have is the comment feed, you can't and don't need to: someone has subscribed to it for it's original purpose, to track all comments on the entry as a separate feed. You only need to play spot the entry if someone who is subscribed to the feed of entries asks you to show them comments on a particular entry, in which case you already know every element of the entry, and you really ought to be able to spot it again in the separate comment feed.

If we were talking about a blank slate, prohibiting the entry in the comment feed would make sense, but we're not: I don't know how long Sam's had them, but I've had entry plus comment feeds for just over a year now, so it'll be tough to sell me on either abandoning something I've done that long, or doing two separate feeds, when it ought to be just a few lines of code to say if $item[$i] != $entry_item.

Placing the original comment in the channel sounds like a fine idea to me. Not having at least one item -- if you don't have any comments, why have a feed? Earlybird subscribers will get a 404 until a comment is posted. Just a thought.

If you think about this from an automated tool perspective, I have to disagree with both of Tim's points. :-)

First, you've presumably already seen the item, and want to subscribe to comments.  If the item is also in the comments feed, the tool needs to determine that yes, indeed it's the same item, and suppress it somehow.  What if it's been edited?  What to do?  And what if, after 17.4 days, there are 40 comments, and your feed is limited to 40 items total?  The original item would fall off the bottom...then the reader tool would need to figure out that the original post is missing.  Doesn't seem like a good, clean solution to me.

And on the 404 until a comment is posted - yikes!  You'd never know the difference between a truly broken link, and an empty feed.  Also a bummer, for tools trying to automate usage of this stuff...

I've seen Sam's weblog before, it doesn't mean a reminder of who I am reading isn't helpful or warranted.

A 404 my not be the most appropriate way to do it. Perhaps a 204 No Content would be better. My points is -- why have a comments feed if there are no comments (yet)?

I try catching up on reading of what’s happening in RSS World. Mark Pilgrim: How to consume RSS safely, Mark’s little prank showing RSS exploit and advice on 10 HTML tag stripping. Some background: RSS Validator ContainsScript, Minimize...

I recently implemented per-item RSS feeds for comments on BitWorking.org. In the process had to decide what the channel level title, link and description should be. I settled on making them the contents of the original item that the comments were...