Let me apologize in advance as this is a topic that I feel passionate and opinionated about. If I'm coming on too strong, please forgive me.
=== Be opinionated===
My first piece of advice is simple: be opinionated. Change the method name to simply <feed_for>. Have it default to doing the right thing. Perhaps give an option to change the default feed format, but default to providing only a single feed format. That's what Microsoft , FeedDemon , Bloglines  and many others would prefer.
If you want, pick RSS 1.0. Or RSS 2.0. Or Atom 1.0. Just pick one. I'd personally recommend that you be a bit forward thinking, like Mozilla  or the Intelligence community ; but if for some reason you want to pick another format from that list; I won't complain.
=== Summary and Content ===
Independent of feed format, my biggest input is that you think a bit more about description. It has a number of problems. The first can be expressed thus: undoubtedly the column in the database from which this element is often sourced is of some string type; in such cases: what would a '<' character in such a column mean? Does it signal the start of markup? Or is it simply a less than character?
My experience is that most string columns in a database are simply plain text. That also tends to be the 'safe' choice in most cases; treating markup as plain text will expose the markup. This , while suboptimal, at least is obvious. In the reverse case, what you have is silent data loss .
If you want to put plain text in an RSS 1.0 or RSS 2.0 <description>, and you are using Builder 2.0 (you *are* using Builder 2.0, aren't you?), then you need to add a .to_xs to escape the string. If you want to put plain text into an Atom <summary> or <content element>, you need do nothing as that is the default.
Now you need a convention (possibly as simple as .downcase.ends_with?("html")) and an a way to override this (perhaps options[:feed][:content_type]?). If content_type=='html', you want to omit the call to .to_xs for RSS 1.0 and RSS 2.0. For Atom, simply do
xml.content(:type => options[:feed][:content_type] || ... || 'text')
Next, consider internationalization / character encoding issues. Builder prefers utf-8; but with Builder 2.0 it will fall back to iso-8859-1/win-1252. This is the right default for a wide number of cases, but it will be wrong in a case that you might care about: native Mac applications.
Finally, consider splitting summary and content. Summary should go into
description in RSS 1.0 and RSS 2.0; but content should go into
content:encoded. This extension enjoys wide support, so it is safe to use . For Atom, summary and content go into summary and content respectively. Additionally, with Atom, you can put XML directly into the content; this may be a reasonable default.
=== Other details ===
You declare xmlns:dc; you really want to use this. Put some author
information into the feed . This goes for all feed versions, though Atom structures this information differently. Author information can either be a single author for the entire feed, or an author for each entry, or both.
The default feed title probably should include the database name.
You omit channel description if there isn't an options which specify this value; doing this is only valid in Atom 1.0; with RSS 1.0 and RSS 2.0 channel description is required.
Omitting language if it isn't specified is probably better than defaulting to en-us.
Re: TTL, before you go there, read .
Entry/Item titles have much the same problems as descriptions in RSS 2.0, only there isn't nearly as much consensus on how to escape it. In particular, in generally it isn't possible find a representation that allows you to express a '<' character in a title. This problem doesn't exist in Atom 1.0.
Overall on the nomenclature: be consistent. You currently have
options[:feed][:item]. This should either be options[:channel][:item]
(matching RSS) or options[:feed][:entry] (matching Atom).
=== PDI ===
Since PDI is potentially the response that this post deserves, let me
point out that resource_feeder doesn't really require much code to