When creating an RSS feed, one should have two audiences in mind: first is your human readers that will be subscribing with their news readers, second are the computers that will be mixing your feed with others, and transforming your feed into other formats (iCal feeds, integrating it into a website, etc.) For committees in Congress, here are some do’s and don’t’s with regard to the second audience.
For announcing committee hearings, here’s the least information-rich way to publish a feed: (And apologies for using brackets instead of for XML tags. I can’t seem to get those to work with WordPress.)
[pubDate](date that the hearing was announced)[/pubDate]
[description]The committee on whatever will meet next Tuesday in our usual meeting location to discuss the terrorism prevention bill. [/descrpition]
No computer can get anything out of that, meaning it would be impossible to transform that feed for any other use. Better would be this:
[name]Committee on …[/name]
[date](date & time of the hearing in a standard date/time encoding[/date]
[description](same as description field above)[/description]
This structure separates out all of the details into distinct fields with clear formats. Converting this feed into iCal format so that someone could integrate the events into their calendaring program would be straightforward.
And, especially in the case of the related-bill item, the bill is referred to not by name (which is ambiguous), or even by number (like H.R. 1234) which is still ambiguous across Congresses, but in a very precise format that is entirely unambiguous. That will let websites like mine cross-reference events in the feed with the bills they are related to, which means it will be easier for people to follow the committee schedule.
Also, including metadata at the top like the actual name of the committee (not, mind you, the title of the feed, like “Hearing Schedule for the Committee….”) is not a bad idea either.