It's now served under a content-type of text/plain when it ought to
be application/rss+xml. Fix that if you can (Apache and .htaccess),
otherwise it _might_ be better as .xml and at least served as text/xml
or application/xml. Don't sweat this though: it's good practice, but
RSS is deliberately robust against it being mis-configured.
Also validate it with feed validatorhttp://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.fivestarbank....
As it stands, it's valid but still needs a couple of tweaks.
You're using RSS 2.0, which is probably the best choice for you,
although the spec is unfortunately badly written and ambiguous. Worth
reading anyway though:
<
http://cyber.law.harvard.edu/rss/rss.html>
Line by line:
<title>Welcome to the Five Star Bank RSS feed</title>
Don't welcome people, tell them what it is. It's not a web site, it's
an RSS feed. They don't "visit" this, they have it delivered to them.
Remeber that they might be reading this on their fridge screen
display, along with the morning's news and last night's baseball
result.
<link>
http://www.fivestarbank.com</link>
Good. This should be to the human-readable website, not any part of
the feed
<description>Where Excellence Exceeds Expectations</description>
Lose the marketing flannel. Put some content here. Try "Five Star Bank
CD rates at 15th May 2007, valid for the next 5 days" or similar
<item>
One item. It's all you need. Not common practice, but entirely valid
in your application.
<title>Current CD Rates</title>
Be careful with words like "current" in any syndicatable protocol (it
might not still be current when yourr reader gets to see it). Only use
them with items that are clearly timestamped, otherwise you will
confuse users.
<link>
http://www.fivestarbank.com/documents/Current_Rates.pdf</link>
I would still be happier if this pointed to a series of files called
"rates at 2007-05-15" etc. Delete them as soon as they're obsolete if
you wish, but at least it avoids confusion of mapping an old
"currrent" onto a new file with a changed rate. If you don't do this
then you are losing most of the advantages of RSS.
You can still make "current" 302 redirect to this week's file.
There's a separate commercial decision to be made as to whether you
want to have your historical rate history visible so easily (by
leaving the old files available). It's your call (but if you ever
make this information publically visible even temporarily, someone
will make a business out of recording it and selling histories of it).
Obviously a single filename kills this anyway.
<description></description>
Put something in there. Probably (for this one-item case) a
restatement of the channel's description.
There are several elements missing from <channel>. Some are important.
<pubDate>
This is vital, because it's how an aggregator identifies the channel /
item as having been updated. If you don't have it, and you don't
change the item link URL, then most correct aggregators will simply
see your content as stale and unchanging, even if the PDF contents
themselves are changing. Put this on both channel and item -- channel
is just the latest pubDate across all <item>s, so in your case they're
currently the same.
<skipHours> & <ttl>
This is poorly done in RSS 2.0, but you should still use it. It's part
of how they hint at the update schedule for the channel. Personally
I'd use the RSS 1.0 syndication module instead, or as well.
<
http://web.resource.org/rss/1.0/modules/syndication/>
<copyright>
This can be important, particularly if you wish to indicate that
financial information brokers can't republish your content. I suggest
reading the Creative Commons site for advice on indicating this.
<managingEditor>
It's now a legal requirement for UK commercial feeds to include this
(with some wiggle room for the technical details of "how"), so as to
identify the legal entity publishing this business communication. I'm
sure US retail banking laws have similar requirements.
There are also elements missing from <item>. Some are already
described, some important.
Remember that many syndication / aggregation environments syndicate
_items_, not _channels_. They'll strip out the items they want from
several sources of channel, then republish them as an aggregation. If
you want to swim in this world, make sure that your <item>s carry the
appropriate metadata, don't just stick it once one the overall channel
and hope.
<guid>
This is essential if you expect any syndication to work. It's how they
recognise <item>s that are different or (in conjunction with pubDate)
have been updated. Don't use isPermaLink=true though unless you're
disambiguated between each weeks' set of rates (as I suggest anyway).
<enclosure>
Your linked content is a PDF, so it's unclear as to whether it ought
to be addressed via a <link> or via <enclosure>. It's possible to use
either. It's better to not use a PDF at all, but to use HTML (with my
Semantic Web pointy hat on). In that case you'd clearly use a <link>
and we'd all start building a world of automatically machine-readable
smart content, intelligent agents and all the rest of it.
However you probably have a corporate brand manager who forces you to
use a PDF so that they can control the exact choice of corporate
typeface. This is a Bad and Wrong policy and the sooner these
dinosaurs are put out to grass the better, but I appreciate that it
happens. So is a PDF a piece of "web content" (use <link>) or is it a
monstrous great piece of opaque brochureware that's only fit to be
downloaded and printed, with no hope of ever being automatically read
and used by agents (use <enclosure>).
