I have finally written up a list of 11 issues I have with the current RSS 1.0 specification.

RSS 1.0 Issues Tracking List

Document Author:

Ian Davis <iand@blog.iandavis.com>

This Version:

Version 1, 30 December 2002

Introduction

This document describes a list of problems and issues with the RSS 1.0 specification dated 2000-12-09 compiled by Ian Davis.

Issue List

1. Issue 1 - Ambiguous wording of repeating element restriction (2002-12-30)
2. Issue 2 - Restrictions on repeating elements hinders RDF usage (2002-12-30)
3. Issue 3 - Required rdf:about attribute on second level elements (2002-12-30)
4. Issue 4 - Required rdf:Seq element for sequencing Items (2002-12-30)
5. Issue 5 - Required typed-node syntax hinders RDF usage (2002-12-30)
6. Issue 6 - Restricted set of URL protocols (2002-12-30)
7. Issue 7 - Overly restrictive wording on format of rdf:RDF element (2002-12-30)
8. Issue 8 - Model only allows a single channel (2002-12-30)
9. Issue 9 - rdf:about URIs must be unique within document (2002-12-30)
10. Issue 10 - Unprefixed resource attributes (2002-12-30)
11. Issue 11 - Minimum of one item in an RSS document (2002-12-30)

Issue 1 - Ambiguous wording of repeating element restriction

Section 5, Extensibility via XML Namespace-Based Modularization

One restriction imposed on sub-elements of top-level channel, image, item, and textinput elements [5.3 <channel>, 5.4 <image>, 5.5 <item>, 5.6 <textinput>] is that these elements may not contain repeating sub-elements (e.g. <item><dc:subject / ><dc:subject /></item>). This proposal only constrains the immediate sub-elements. Any further depth (of rich content or repeated elements) is already well-defined using RDF syntax.

This paragraph is ambiguous. Reading the text literally, one concludes that "sub-elements of channel, image, item and textinput elements may not contain repeating sub-elements." However the example given indicates that it is the sub-elements of the channel, image, item and textinput elements that may not repeat.

Issue 2 - Restrictions on repeating elements hinders RDF usage

Section 5, Extensibility via XML Namespace-Based Modularization

See also, issue 1

One restriction imposed on sub-elements of top-level channel, image, item, and textinput elements [5.3 <channel>, 5.4 <image>, 5.5 <item>, 5.6 <textinput>] is that these elements may not contain repeating sub-elements (e.g. <item><dc:subject / ><dc:subject /></item>). This proposal only constrains the immediate sub-elements. Any further depth (of rich content or repeated elements) is already well-defined using RDF syntax.

This restriction is arbitrary and no explanation for it is given in the specification.

Issue 3 - Required rdf:about attribute on second level elements

Section 5, RDF

Each second-level element (channel, image, item, and textinput) must include an rdf:about attribute

This restriction is arbitrary and no explanation for it is given in the specification. It is presumed that this restriction was imposed so as to enable the cross-reference of items with the 'table-of-contents' described in the subsequent bullet point. This explanation does not suffice to explain why elements such as image and textinput must have an rdf:about attribute. This restriction, in conjunction with the restriction in Issue 4, prevents the use of anonymous Items. In the current RSS 1.0 RDF model the following triple is asserted about the subject of each item:

<itemUri> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://purl.org/rss/1.0/item>

In the author's opinion, this triple is extraneous since it is an artifact of the RSS channel structure. The type of the resource described by the Item should not be an RSS Item, most likely it is an HTML page.

Proposal: Remove this restriction. Suggest the use of rdf:ID or anonymous nodes. Example:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns="http://purl.org/rss/1.0/">
<channel rdf:about="http://example.com/">
<title>Example</title>
<link>http://example.com/</link>
<description>Digital explorations and experiments</description>
<items>
<rdf:Seq>
<rdf:li rdf:resource="#item1" />
</rdf:Seq>
</items>
</channel>
<item rdf:ID="item1">
<title>An item</title>
<link>http://example.com/item1</link>
</item>
</rdf:RDF>

Issue 4 - Required rdf:Seq element for sequencing Items

Section 5, RDF

A channel-level RDF table of contents associating the image, items, and textinput with the channel at hand

This addition to the RSS 0.90 specification was introduced to resolve the problem of ordering Items when the RSS has been parsed to its base triples. It also serves to build an association between Items and the containing Channel.

However, this restricts the RSS model to that of ordered items and there are use-cases of RDF Site Summary that do not require ordering, or have multiple orderings. For example: use of RSS to describe site maps (no ordering), use of RSS as to list comments or job listings (multiple orderings)

If the multiple-element restriction Issue 2 is lifted then the Items could be contained directly within the Channel element as anonymous nodes. This would preserve the association between Item and Channel.

Proposal: Make this element optional.

Issue 5 - Required typed-node syntax hinders RDF usage

Section 5, RDF

In order to keep the RDF and plain XML views of RSS 1.0 in synch as much as possible, RSS 1.0 only supports usage of typed-element RDF syntax in the core elements.

This restriction was imposed to preserve backwards compatibility with RSS 0.90. However, it now places undue restrictions on the output of general RDF producers and prevents alternative representations of RSS in RDF such as the Abbreviated Syntax for use within HTML documents.

Proposal: Remove this restriction.

Issue 6 - Restricted set of URL protocols

Section 5, URLs

As a measure to assure backward compatibility with RSS 0.9, only the following schemes are acceptable in url and link elements: http:, https:, ftp:. mailto: is acceptable in the textinput's link element only.

This restriction was imposed to preserve backwards compatibility with RSS 0.90. However, this restricts the utility of RSS 1.0 for describing non-HTTP or FTP based resources. An RSS application that supports other URI schemes, e.g. freenet cannot produce RSS that describes those resources.

Proposal: Relax this restriction to include a reference to IANA-registered URI schemes.

Issue 7 - Overly restrictive wording on format of rdf:RDF element

Section 5.2, <rdf:RDF>

While any valid namespace prefix may be used, document creators are advised to consider "rdf:" normative. Those wishing to be strictly backward-compatible with RSS 0.9 must use "rdf:".

Syntax: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax- ns#" xmlns="http://purl.org/rss/1.0/">

Requirement: Required exactly as shown, aside from any additional namespace declarations

The statement in the Requirement contradicts the text in the preceding paragraph. The paragraph text clearly states that any valid namespace prefix may be used for the RDF namespace. However the restriction states that the first element in the document must declare rdf to be the RDF namespace prefix and for the RSS elements to be unprefixed.

This issue was recently the subject of some discussion on the RSS-DEV mailing list.

Proposal: Reword the restriction to the single word 'Required' as in subsequent sections.

Issue 8 - Model only allows a single channel

Section 5.2, <rdf:RDF>

Model: (channel, image?, item+, textinput?)

This restriction was imposed for to remain backwards compatible with RSS 0.90.

Allowing multiple channels to be described within a single file would be more efficient and would allow the sharing of items among multiple channels.

Proposal: Alter the model to allow multiple channel elements.

Issue 9 - rdf:about URIs must be unique within document

Section 5.3, <channel>; Section 5.5, <item> et al.

The URL of the channel element's rdf:about attribute must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the channel.

This restriction is arbitrary and no explanation for it is given in the specification.

Issue 10 - Unprefixed resource attributes

5.3.5 <items>, plus examples

Syntax: <items><rdf:Seq><rdf:li resource="" />

Use of the resource attribute without a namespace prefix is considered bad practice and is discouraged.

Proposal: Change syntax and examples to use rdf prefix .

Issue 11 - Minimum of one item in an RSS document

5.5 <item>

There may be a minimum of one item per RSS document.

This restriction is arbitrary and no explanation for it is given in the specification. It prevents the assertion that a particular channel has no associated items which may be the case for RSS files that are dynamically generated in response to HTTP date headers (i.e. shows that there have been no new items since the date specified).

Proposal: Remove this restriction.