Continuing further on the idea of lightening the RSS load by allowing the client to request a subset of the elements contained in a newsfeed, here are a few more thoughts:

First, to reduce processing requirements on the server, rather than dynamically generating the feed based on the elements requested, the server could keep a few common alternative versions of the feed cached statically, and deliver the lightest-weight version which contains all of the requested elements.

Second, in the request, since the client may not know which elements a feed contains, the server would obviously have to be able to ignore requested elements which didn't exist.

Third, the client should be able to request alternative elements, in case the feed doesn't contain a preferred element. The most obvious example would be pubDate and dc:date. Some feeds contain one, some the other, and some neither. So the client may request the pubDate, but if it doesn't exist (and only if it doesn't exist--in case both are included in the feed), it could request dc:date as an alternative.

Fourth, the request API will need to be formatted such that namespaces can be specified, at least when requesting elements defined by extensions to RSS (like dc:date). Perhaps a method could be devised to specify a default namespace (as required for RDF feeds), which could be ignored when requesting 2.0 feeds and any others which do not have a namespace associated with their core elements. Otherwise, the client would need to know which version of RSS was being requested in order to know whether and how to specify a default namespace.

RSS 1.0 and 2.0 really should have different names!