User guide

From cbwiki.net
Jump to: navigation, search
Please note that this page relates to a deprecated version of RSS-CB. Please find links to the current version via the RSS-CB home page

Contents

Introduction

The user guide examines in greater depth the information set out in the RSS-CB specification. It also discusses the intended uses of RSS-CB, and recommends best practices for the implementation of RSS-CB.

Intended uses of RSS-CB

End-user RSS feeds

Most producers of RSS-CB content intend to create news feeds for consumption by human users via RSS reader software. The best practices aim to ensure optimal display of such feeds.

Aggregation

The RSS format is well-suited to automated harvesting by machine processes (aggregation). In fact, the RSS-CB project ensued from a request by the Federal Reserve Bank of New York for a reliable source of Bank for International Settlements news items. The BIS, which compiles these news items from various central banks, also saw RSS-CB as an opportunity to enhance its own information gathering process.

Other institutions may be interested in developing such automated processes, as a way of reliably aggregating information from numerous central banks at once. RSS-CB namespaces become especially significant for this. Specifically, Dublin Core metadata can enhance the utility of aggregated content.

Statistical data

Users of central bank information are often interested in small pieces of statistical data, such as a foreign exchange rate, or an overnight lending rate. The RSS-CB project will examine and recommend consistent and efficient means through which RSS-CB can deliver such data to users and aggregators.

See also: sample RSS-CB 1.0 file.

Authors/Contributors

Paul Asman, Federal Reserve Bank of New York
Christine Sommo, Federal Reserve Bank of New York
Dan Chall, Federal Reserve Bank of New York
Elena Atayeva, Federal Reserve Bank of New York
Mike Eltsufin, Federal Reserve Bank of New York
Allen Galiza, Federal Reserve Bank of New York
San Cannon, Federal Reserve Board of Governors
Butch Easton, Federal Reserve Board of Governors
Julie Jackson, Federal Reserve Board of Governors
Noé Palmerin, Banco de México
Timo Laurmaa, Bank for International Settlements
Brent Eades, Bank of Canada
Suzanne LeBlanc, Bank of Canada
Marcello Di Pietro, European Central Bank

Version

Latest Version: http://www.bis.org/cbrss/1.0/spec/ 1.0.0: this version

Status

Draft

RSS-CB syntax and best practices

XML declaration

<?xml version="1.0"?>

Why: According to the RSS 1.0 specification, it is not mandatory to begin an RSS file with this declaration. However, doing so will ensure more reliable reading of the file by parsers, user agents, and other software. It also allows the specification of different character encodings through the use of the encoding attribute.

Requirement: Required

<rdf:RDF>

The RDF element contains namespaces as instances of the xmlns attribute. Four are required, as indicated below. Custom namespaces, either for an individual institution or a group of institutions (such as RSS-CB), are optional. Before adding an element to a custom namespace, care should be taken to ensure that the concept is not already covered in one of the required namespaces.

The RDF element requires one and only one instance of the channel child element, and one or more instances of the item child element. The RDF element permits one and only one instance of the image child element; it is optional. RSS-CB permits no instance of the textinput child element; it is prohibited. RSS-CB prescribes an order for the child elements of the RDF element to facilitate validation.

Namespaces

An RSS-CB file must contain the four following namespace declarations, for which the attribute values should be the URIs of the latest official specifications.

The RDF namespace, with the recommended prefix rdf:
Requirement: Required

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

The RSS 1.0 namespace, the recommended default namespace, with no prefix:
Requirement: Required

xmlns="http://purl.org/rss/1.0/"

The Dublin Core namespace, with the recommended prefix dc:
Requirement: Required

xmlns:dc="http://purl.org/dc/elements/1.1/"

The Qualified Dublin Core namespace, with the recommended prefix dcterms:
Requirement: Required

xmlns:dcterms="http://purl.org/dc/terms/"

An RSS-CB file can also optionally declare custom namespace(s) for extensions used by individual institutions or groups of institutions:
Requirement: Optional

xmlns:cb="http://www.centralbanks.org/rss/"
xmlns:onecb="http://www.particularcentralbank.gov/rss/">

<channel>

The channel element in RSS 1.0 has seven child elements, each of which can have at most one instance, and one required attribute, rdf:about. Four of the child elements are required, each having one and only one instance: title, link, description, items, and dc:license. The other two child elements, image and textinput, are optional in RSS 1.0. Image remains optional in RSS-CB, but textinput is prohibited. RSS-CB prescribes an order for the child elements of the channel element to facilitate validation.

rdf:about

The RSS 1.0 specification does not explicitly prescribe the source of the value of the channel's rdf:about attribute. RSS-CB 1.0, however, stipulates that its value must be the URL of the current RSS feed. Thus, an RSS feed whose URL is http://yoursite/press.rss would have this value of rdf:about:

<channel rdf:about="http://yoursite/press.rss">

Why: One of the roles of RSS-CB 1.0 is to allow automated aggregators to collect feeds from multiple institutions, to be stored, for example, in a database. In such scenarios it may be important to know the original URL for a given RSS file.

<title>

Maximum length: 40 characters recommended.

Why: The RSS specification gives 40 characters as a suggested maximum. Because many RSS user agents will display no more than this number of characters, RSS-CB upgrades this to a recommendation.

Best practice: Not all RSS readers display the channel title. For those that do, creators of RSS-CB 1.0 feeds should observe the following conventions:
  • Use the name of the institution as the first element in <title>, followed by a colon and a space. Example: New York Fed: events
  • The name used for the institution could be an acronym or a full name. It is included in the 40-character maximum.
  • Avoid superfluous words where possible. Example: Use New York Fed: announcements instead of New York Fed: announcement feeds.
  • If the institution's name does not indicate its country, insert an ISO 3166 Country Code.

<link>

Best practice: The <link> should be to the landing page of the RSS feed - the page that lists and/or describes the RSS feeds available for a given site or site section.

If the feed has a page devoted to it (as on the web site of the New York Fed, for example), the URL is of that page. Otherwise, if the feed is from an institution’s home page, the URL is of that page, and if the feed is from a departmental page, the URL is of that page.

Why: Using <link> this way will allow users to return to the pertinent sections of the site to learn if new RSS feeds are available, or to discover other site content related to the subject matter of the feed.

<description>

Best practice: This element must not be empty, and should present a concise, unambiguous description of a channel's content, to a maximum of 500 characters.

Why: While not all RSS readers display the channel description, it should be meaningful for those that do.

<image>

If there is an <image> as a child of <channel>, there must also be an <image> main element. Discussion of image is deferred to that section.

<items>

See Specification document for the syntax of this element.

<dcterms:license>

Best practice: The <dcterms:license> should be to the landing page of the feed usage license.

Why: Using <dcterms:license> this way will allow users to return to the pertinent section of the site to learn if the license has been updated.

<image>

The <image> element is used to display a graphic for a channel. Typically this image will be an organization's logo or wordmark. Not all RSS software will display an <image>.

The RSS 1.0 specification recommends, following convention and version 0.9, that the dimensions of the image be 88 pixels wide by 31 pixels high. Observing this recommendation will help ensure correct rendering of images in reader software, and RSS-CB endorses it. RSS 0.91 did permit image sizes from 1 to 400 pixels wide and 1 to 144 pixels high; RSS-CB discourages this.

This element is required if there is an <image> child of <channel>. RSS-CB prescribes an order for the child elements of the image element in accord with its practices with the RDF and channel elements, where the order facilitates validation.

rdf:about

There are two requirements for the value of this attribute: that it match the value of rdf:resource of the image child of channel; and that it be unique in respect to any other rdf:about attributes in the document.

RSS-CB recommends that the value be the URL of the image. Why: This will help ensure that it is unique within the document.

<title>

This free text value corresponds to the contents of the alt attribute in the HTML specification. As that specification states, "For user agents that cannot display images, forms, or applets, this attribute specifies alternate text." See the HTML specification for further guidelines.

<url>

The value of this element corresponds to the value of the src attribute in the HTML specification. As that specification states, it "specifies the location of the image resource." It should also match the value of the rdf:about attribute of the parent image.

<link>

This has the same value as the link child element of channel. Guidelines are found here.

<item> element

There must be at least one item. The RSS 1.0 specification has no upper limit, but recommends no more than 15 items for compatibility with RSS 0.9 and 0.91. RSS-CB finds this recommendation obsolete, and does not endorse it. RSS-CB prescribes an order for the child elements of the item element in accord with its practices with the RDF and channel elements, where the order facilitates validation.

Below we list all RSS-CB fields that appear in the specification. Some are common to all application types, but many are used only in specific applications of RSS-CB. Developers should refer to the various Application Guides for information on relevant fields and more specific notes on how to use common fields within each application.

Core elements

rdf:about

There are two requirements for the value of this attribute:

  • that it match a value of rdf:resource in the list of items
  • that it be unique in respect to any other rdf:about attributes in the document.

The RSS 1.0 specification also recommends that the value of this attribute match the value of the link child of this element. (The wording is "should ... if possible.") RSS-CB endorses this recommendation. Given the uniqueness requirement for the value of this attribute, following this recommendation limits RSS-CB feeds to one RSS item per URL (which may include an anchor tag).

Why: The value of link must be a URL, while the value of rdf:about must be a URI. A URL picks out a web page, while a URI identifies an artifact that may or may not be a web page. Matching the value of rdf:about to that of link has the effect of requiring that the URI pick out a web page, which makes it useful to consumers of RSS-CB feeds.

<title>

The contents of the item title is at the discretion of the institution providing the RSS feed. This is the title that will be displayed by the reader for human consumption.

Maximum length: 100 characters.

The RSS 1.0 specification suggests 100 characters as a maximum. Because many RSS user agents will display no more than (and possibly not even) this number of characters, RSS-CB strongly recommends adherence to this maximum.

Usage: required

Discussion:

<link>

Proposal: The link points to the landing page for this particular item as chosen by the institution. It could be a dedicated landing page, an abstract page for a paper, or any other valid URL. This URL should point to whatever the institution considers the main landing page for the content.

Usage: required

Discussion: If the recommendation given for the rdf:about attribute of the item is followed, this URL matches the value of that attribute. This entails that the values of this element be unique within the document. Uniqueness may be accomplished by appending anchor tags to the end of the URL. If the tags do not exist within the document they will have no effect on document navigation but would make the attribute value unique with respect to string comparison.

<description>

Proposal: Recommended is to have the entire substantive contents of the item in the description, if possible. Otherwise, an abstract should be used here.

Usage: required

Discussion: The RSS 1.0 specification recommends a maximum length of 500 characters, which RSS-CB endorses.

The amount of information given in description depends on the intentions for the RSS feed. An institution that uses RSS feeds to drive traffic to its web site may wish to keep descriptions brief. An institution that wishes to offer complete information in different formats may wish to be more prolix.

<dc:language>

Proposal: Indicates language of the content described by the item. Use the standard found in ISO 3066

Usage: recommended, especially for some application types such as research papers.

Discussion: The item links to one specific resource, so there should be one specific language indicated by the feed. In an international context such as that for central banks, and with the possibility of aggregated feeds, this field could be useful for any content.

The language of the feeds is a separate issue, and could be determined by a language attribute for various elements. The language of the content should instead by determined by a language element.

<dc:creator>

Proposal: This contains the abbreviation that signifies the identity of the institution. It contains no blanks.

Usage: required

<dc:date>

Proposal: Corresponds to date RSS feed updated. For date formatting information see W3 specs

Usage: required

Discussion: This field should follow the Dublin Core scheme which provides for date and time precision. Failure to include the time component will result in the display as midnight in some readers.

<cb:application>

Proposal: Denotes that the item belongs to one of the specified RSS-CB applications. Valid values: <cb:application> is text to be selected from the set event, news, paper, speech, statistics.

Usage: required when the item does belong to one of the applications. It may be that an item in the RSS-CB feed does not correspond to one of these, in which case it can be left out.

Discussion: This field is used by aggregators to differentiate what kind of items are contained in the feed, and to enable validation of the various schemas. It is specified at the <item> level, as feeds may contain a mix of items from different applications, depending on how the institution wishes to structure their feeds for the public.

<cb:simpleTitle>

Proposal: A version of the title without any additional adornments such as date, institution and so on. Aggregators or re-purposers of the feed can then adapt this title.

Usage: required for certain application types

Discussion: For example, ECB might publish an item with the title "15/12/2006 Euro notes dissolve in beer". The cb:simpleTitle would be "Euro notes dissolve in beer", which an aggregator could then choose to publish as "15 Dec ECB: Euro notes dissolve in beer"

<cb:occurrenceDate>

Proposal: Corresponds to the actual date the speech took place, the event starts, the item was published and so on. This value should remain constant when repurposed, however aggregators may modify the dc:date value if necessary in order to control the order in which items appear. For date formatting information see W3 specs.

For example, a press release may be dated for official release as 2007-31-01. The dc:date value could then be 2007-31-01T19:20+01:00 on the website of the original source for the item. An aggregator may then use a different dc:date value - perhaps the time when the item came into its own system, which could be several days later - but should still be able to refer to the original <cb:occurrenceDate> to publish information on the actual release date.

Usage: required for certain application types

Discussion: This field should follow the Dublin Core scheme which provides for date and time precision. Failure to include the time component will result in the display as midnight in some readers.

<cb:keyword>

Proposal: Descriptive keywords and phrases of the item's contents. These are determined by individual institutions - there is no common taxonomy proposed for RSS-CB keywords.

Usage: recommended for publications, optional otherwise

Discussion: This field cannot contain more than one keyword/phrase. List each keyword as an individual item.

<cb:resource>

Proposal: Used to identify media items such as audio/video of speech, PDF, etc.

Elements: Each resource has a cb:title, cb:link and cb:description.

Usage: optional

Discussion:This field cannot contain more than one resource. List each resource as an individual item.

Suggestion: the cb:title should be read as an expansion upon the title of the main item being described (i.e. <item><title>), rather than reiterating all of the details. The description can be taken as a fuller explanation of the resource.

Example:

<cb:resource>
  <cb:title>Powerpoint presentation</cb:title>
  <cb:link>http://www.bankofmolvania.yy/speeches/20061219a.ppt</cb:link>
  <cb:description>Powerpoint presentation accompanying the speech by 
    Georgios Hamb, Governor of the Bank of Molvania, on international 
    pension issues at the Hilton Hotel in 
    New York, 18 December 2006.</cb:description>
</cb:resource>
<cb:resource>
  <cb:title>RealPlayer audio feed</cb:title>
  <cb:link>http://www.bankofmolvania.yy/speeches/20061219a.rm</cb:link>
  <cb:description>Audio feed in RealPlayer format of the speech by 
    Georgios Hamb, Governor of the Bank of Molvania, on international 
    pension issues at the Hilton Hotel in 
    New York, 18 December 2006.</cb:description>
</cb:resource>
<cb:person>

Proposal: Use to describe an individual (or institution) that is associated with the item. The role of the individual in relation to the item is described using the type attribute.

Attributes: type (valid values - "speaker", "author", "editor").

Elements: cb:givenName, cb:surname, cb:personalTitle, cb:nameAsWritten, cb:role.

cb:nameAsWritten is required. The others are recommended when the values are those for an actual person rather than an institution, in which case cb:surname is required.

cb:role is itself recommended. If present, it has the required child element of cb:jobTitle and the optional attribute cb:body.

Usage: As determined by the specific application. For some, such as speeches, it would be required, for others, optional.

Discussion: Where an institution performs the role a person might otherwise do (e.g. it is identified as the author of a document), use only the cb:nameAsWritten element.

Multiple roles are acceptable, but a single instance of cb:givenName and cb:surname is recommended.

Example:

<cb:person type="speaker">
  <cb:givenName>Hng Kiang</cb:givenName>
  <cb:surname>Lim</cb:surname>
  <cb:personalTitle>Mr</cb:personalTitle>
  <cb:nameAsWritten>Lim Hng Kiang</cb:nameAsWritten>
  <cb:role>
    <cb:jobTitle>Deputy Chairman</cb:jobTitle>
    <cb:body>Monetary Authority of Singapore</cb:body>
  </cb:role>
  <cb:role>
    <cb:jobTitle>Minister for Trade and Industry</cb:jobTitle>
    <cb:body>Government of Singapore</cb:body>
  </cb:role>
</cb:person>

Elements used in specific applications

<dcterms:audience>

Proposal: The group of people that listened to the speech.

Usage: recommended for some application types

Discussion: This may or may not also be the location of the speech.

<dcterms:extent>

Proposal: Indicates the size of the content in pages and/or bytes.

Usage: Optional. Could be used in specific applications, such as research papers.

Discussion: It is a standard practice to label links on HTML pages to PDF documents, for instance, with the size of the file. Catalogs of written work usually refer to the number of pages. Since RSS may allow users to bypass this normal source of metadata, and its very purpose is to manage it, supplying these two fields may be of value to a dedicated CB aggregator.

<cb:venue>

Proposal: Physical location of the speaker during the speech

Usage: recommended for some application types

Discussion: Note that audience and venue may be the same. If these two fields will be identical, use only the audience field.

<cb:eventDateEnd>

Proposal: Corresponds to the date that the event ends and should include day, month, year. If the event starts and ends on the same day, this element can be omitted.

Usage: optional and currently used only for the Events application

Discussion:

<cb:byline>

Proposal: The full byline for the paper or publication as it appears in the published version

Usage: Recommended for some applications (e.g. Research papers).

Discussion: In addition to supporting each author's name in cb:person, it is worthwhile to have a dedicated element for the complete byline, with all the author names in proper order and with all the necessary punctuation and diacriticals. This approach makes it unnecessary for a client application to reconstruct the bylines for display to the users' screens.

<cb:publicationDate>

Proposal: A string representing the stated date for the publication, not necessarily the date of the actual "creation" of the document. For some papers, this will be some month-year representation; for others it may be a quarterly or seasonal indicator. For example "Spring, 2006", "1st Quarter, 2008", "2004-5"

Usage: Recommended for some applications (e.g. Research papers).

Discussion: This date is not meant to be represented in a date format, per se. It may indicate when a particular paper was made available, but is a formal date label that can be chosen for institutional reasons.

<cb:publication>

Proposal: Text field containing the name of the journal or working paper series, if one exists.

Usage: Recommended for some applications, such as research paper.

<cb:issue>

Proposal: Text field containing alpha-numeric ordinal indicator.

Usage: Recommended for some applications, such as research paper.

Discussion: This is where this information can be provided, using appropriate fields: issues may have numbers, months, quarters, two month names, two quarter or season names, volume numbers and issue numbers.

<cb:JELCode>

Proposal: Codes from a controlled vocabulary list corresponding to the official subject listing used by the Journal of Economic Literature. Multiple instances, one for each code. Codes can be one digit or more, and should not spell out the name of the category.

Usage: Recommended for some applications, such as research paper.

<cb:institutionAbbrev>

Proposal: This contains the abbreviation that signifies the identity of the institution. It contains no blanks. It is usually identical to a part of the title.

Usage: Required for some statistical applications.

<cb:country>

Proposal: This contains the ISO 3166-1 country code of the country reporting the rate, followed by a colon. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the first field of the title.

Usage: Required for some specific statistical applications.

<cb:baseCurrency>

Proposal: This contains the ISO 4217 currency code that signifies the base currency. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the fifth field of the title.

While some central banks may always report exchange rates in their own currency, this is not always the case. The New York Fed, for example, reports most exchange rates in United States dollars, but it reports the Australian dollar, the Euro, the New Zealand dollar, and the British pound in terms of those currencies. The Bank of Canada reports USD-CAD rates in both directions:

CA: 1.1165 CAD = 1 USD 2006-08-14 BOC closing

CA: 0.8957 USD = 1 CAD 1006-08-14 BOC closing

Since consumers of RSS exchange rate feeds may be taking rates from several different institutions, the inclusion of a base currency is important even for institutions that always use their own currency as the base currency.


Usage: Required for some specific statistical applications.

unit_mult attribute

Proposal: This optional attribute contains the value of the unit multiplier, an exponent of 10. A unit_mult of 2, for example, indicates that the baseCurrency is stated in terms of 100 units. The default value for this attribute is 0, for stating the baseCurrency in terms of 1 unit.

<cb:targetCurrency>

Proposal: This contains the ISO 4217 currency code that signifies the target (or price, or counter) currency. In the schema for exchange rates, the value will be limited to the enumerated values in a code list. The value is identical to the third field of the title.

Usage: Required for some specific statistical applications.

<cb:value>

Proposal: This contains the value of the observation. The value will be identical to one of the fields in the title. See the relevant Application Guides for more information.

Usage: Required for statistical applications.

frequency attribute

Proposal: This contains the value of the frequency. The value maybe limited to the enumerated values in a code list - please see the relevant application guides.

decimals attribute

Proposal: This contains the number of decimal places used to express the value. The value maybe limited to the enumerated values in a code list - please see the relevant application guides.

unit_mult attribute

Proposal: This contains an exponent of 10. The default is 0, for stating the value in terms of 1 unit.

units attribute

Proposal: This string contains a description of the units of the datum. It can be a text string with blanks or a value from the enumerated values in a code list. It is recommended for statistical data that are not clearly in rates. Please see relevant application guide.

<cb:rateType>

Proposal: This contains a free text value describing the rate type as identified by the reporting institution. The value is usually identical to one of the fields in the title.

Usage: Required for some statistical applications.

<cb:rateName>

Proposal: This contains the higher-level local name for a rate. For the New York Fed, Fed Funds denotes a set of observations that include the daily effective rate, the high and low points in the range for the observation period, and more. This field indicates only the higher-level name. The value is usually identical to a part of the title.

Usage: Required for some statistical applications.

<cb:transactionType>

Proposal: This contains a free text value describing the transaction type as identified by the reporting institution. It is a refinement of the transaction name. The value is usually identifical to a part of the title.

Usage: Required for some statistical applications.

<cb:transactionName>

Proposal: This contains the higher-level local name for the transaction. For the New York Fed, CouponPurchase represents one of three types of permanent open market operations conducted. The value is usually identical to a part of the title.

Usage: Required for some statistical applications.

<cb:transactionTerm>

Proposal: This contains the term of the transaction. At the New York Fed, 1day is the transaction term and repo is the is the transaction name. The value is usually identical to a term concatenated to a part of the title.

Usage: Recommended for some statistical applications.

<cb:topic>

Proposal: This contains a string representing the economic area to which the data belong. These can be institution specific. Abbreviations are acceptable as long as they can be easily interpreted from information provided in other fields or draw from established code lists.

Usage: Recommended for some statistical applications.

<cb:dataType>

Proposal:This containts a string with additional information about the datum provided. Indications of measure, seasonal adjustment, change calculations should be indicated here.

Usage: Recommended for some statistical applications.

<cb: coverage>

Proposal:This contains a string indicating the sector, industry or region to which the datum is applicable.

Usage: Recommended for some statistical applications.

Dublin Core and/or custom namespace elements

Note that Dublin Core elements can be optionally entered by an institution, but any that are not mentioned within the RSS-CB specification are not required and the contents of any related data is at the institution's own discretion. Be sure to check whether the element is part of the Dublin Core (dc) or Dublin Core (dcterms) terms namespaces. See [1] for a full list.

One of particular interest is dc:creator. It is not formally contained in the RSS-CB specification, due to it being an optional field with no special guidelines within RSS-CB, but it is worth noting that it has an important use within general RSS aggregators. Many feed readers (e.g. Google Reader) will list entries using dc:creator as an author "by Xxx Yyy". However, within RSS-CB we still need to specify our individual authors in cb:person elements, and the entire authorship line for some applications, such as research papers, using cb:byline. dc:creator doesn't quite fit the requirements these other elements do, but feed creators may wish to use it in addition to cb:person and cb:byline.

Guidelines for general attributes

This section contains guidelines for attributes applicable to elements appearing throughout the document, rather than attached to a particular element.

xml:lang

This attribute specifies the language of the text child of that element. For specifying the language of the underlying resource, see dc:element.

The xml specification permits xml:lang as an attribute of any element. For example, in <title xml:lang="en">the title</title>, xml:lang indicates that "the title" is English-language text. The attribute makes no claim about the language of the title of any underlying resource. The Bank of Canada, for example, may have a French language feed that includes links to research articles available only in English. In the RSS feed, the item could have a French title while the underlying resource does not.

xml:lang is recommended for any element with free text as a child, most notably title and description. For any element that takes a formatted value (e.g. date) or a value from a controlled vocabulary, there is no language choice, and the use of this attribute is discouraged.

Keeping items current

The method of outdated content removal from RSS feeds is generally left up to the content provider.

There are two main approaches to old content removal:

  • ensure that some maximum number of items is not exceeded. RSS 0.91 feeds used to be limited to only 15 items per feed, and many "modern" feeds still honor the 15-item limit, either for backwards-compatibility (not really relevant anymore, as RSS 0.91 has been deprecated and none of the subsequent RSS formats impose a such a limit) or simply because 15 seems to be a reasonable default number.
  • purge all items older than a certain age. This is especially useful for feeds that are updated very rarely (if a new item is only added once a month, would anyone really be interested in "news" that is 15 months old?) or very frequently (for a feed that gets updated with 50 items per day, keeping at least one day's worth would prevent information from leaving the feed before RSS readers had a chance to pick it up).

There are also special situations in which a custom removal strategy is needed. For example, if a seminar that's coming up in 6 months is added to the calendar, RSS feed, either removing all but the last 15 events or removing the ones created more than a month ago will take information about the seminar out of the feed long before it occurs, giving the new feed subscribers no chance to learn of the event. In the case of the event calendar, it may be more useful to only remove the events that have already took place. Since the feed regeneration is done on the server side, the custom purge algorithm is not difficult to implement.

Licensing the use of your feeds

While your RSS-CB feeds will be viewed primarily by individual users of your site, it's important to remember that the RSS format is also used extensively to 'syndicate' news items -- that is, to republish them on other websites.

This raises a variety of legal considerations for producers of RSS feeds. Your institution should develop and publish licensing terms that specify how and by whom your feeds may be republished. Some issues to consider:

Accreditation

You will likely want to stipulate that news items originating from your organization are clearly identified as such.

Back-linking

Ensure that viewers of your republished content have a way of linking back to your website (in instances where the republisher has not provided direct links to your news items.)

Unacceptable use

Specify which types of sites may not republish your feeds; pornography sites, for example, or those that promote hatred or illegal activities.

Use of your logo or wordmark

Your institution's policies may restrict the use of your logo/wordmark by other parties.

Example

For an example of a comprehensive RSS licensing terms document, see the BBC's website.