RSS 1.1: RDF Site Summary (DRAFT)

RSS 1.1 is a content syndication format intended to update and replace the popular RSS 1.0. It is an application of the W3C's RDF and XML languages. It has better internationalization support, utilizes more up-to-date facilities of its constituent languages than RSS 1.0, and fixes a number of other issues with the RSS 1.0 specification. RSS 1.1 is as extensible as RSS 1.0 and can even make use of its extension modules.

Status

This is an independent draft not supported or endorsed in any way by the RSS-Dev Working Group or any other organization. This work is licensed by its authors under a Creative Commons License, by-nd v2.0 or later; the format that it defines, on the other hand, is not under any license and may therefore be freely used by anyone. Please send any comments about this work, or corrections, directly to the authors. Public discussion of the issues surrounding RSS in general can be had on the rss-dev mailing list.

1. Introduction and Background

RSS 1.1 is an extensible content syndication format based on RDF and XML. It allows content distributors such as news portals, webloggers, and other providers of up-to-the-minute or static content to publish their information in a machine readable and repurposable format. For consumers of such information, it hence alleviates the problem of having to check a large collection of sundry websites while remembering simultaneously which items have been read. Providers can thereby increase the likelihood that their content will be read by consumers more frequently.

An example of a valid RSS 1.1 document is given in section 3. Further information about the format in general can be obtained from the Rough Guide to RSS 1.1.

2. Motivation

In its other guises, e.g. RSS 0.91, RSS 2.0, and Atom, content syndication of this kind has been enormously successful, and requires no justification of its general potential. The addition of yet another version, however, to the current proliferation of RSS variants necessitates its rationale being documented.

Many sites understand the benefits of syndication, and have provided RSS feeds to achieve a variety of goals, from increased readership to providing instant updates on content. A number of formats have emerged, each of them offering aspects that others do not. RSS 1.0, due to its RDF based nature, offers a variety of benefits. Thus far, however, uptake for RSS 1.0 has been relatively limited, due to the difficulty in creating conforming documents in comparison to other syndication formats. Duplication of data, as well as a generally confusing specification, have left much to be desired from the developer perspective, leading to a less-than-impressive number of RDF-based RSS documents in the wild.

This specification is therefore made available by users of the RSS 1.0 format who wanted to update the specification to make use of the latest features of RDF in order to reduce the redundancy in the format, and the ambiguity in the specification, while at the same time implementing a series of bugfixes from the lessons learned in developing the other descendent of RSS 1.0, Atom.

The RSS 1.1 specification addresses bugs and issues raised against 1.0, and is targeted at users of RSS 1.0 who do not want to migrate to Atom. A full list of changes from RSS 1.0 is given in Appendix C.

3. Conformance Definition

This section is normative. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

A conformant RSS 1.1 document is one which meets all of the following conformance criteria:

It is RECOMMENDED that RSS 1.1 documents be encoded using UTF-8. The following is an example of a conformant RSS 1.1 document:

4. Syntax and Semantics

This section contains a series of usage notes derived from the conformance criteria for RSS 1.1 documents, and a prose definition of RSS 1.1 annotated with fragments of a RELAX NG Compact schema, the full normative version of which can be found in section 5.

As a consequence of [CC1-RNC], every RSS 1.1 document instance must be well-formed XML. This means, for example, that RSS 1.1 documents encoded as iso-8859-1 must begin with an XML prolog containing an encoding declaration, unless the encoding is determinable by a higher-level protocol (e.g. through use of a charset parameter in a MIME Content-Type header). For the example of a iso-8859-1 encoded document, the value of the XML prolog may be:

The uniqueness constraint on rdf:about attribute values, [CC5-RDFABOUT], is for backwards compatibility with RSS 1.0. Conceptually, the rdf:about attribute may be thought of as having the same constraint as XML IDs, only the range of allowed values is that of the XSD anyURI datatype. See the usage notes for the item element for more information.

Usage note: Any RSS 1.0 extension module may be employed in an RSS 1.1 document as long as it is done in such a way as to comply with the conformance criteria in this section.

4.1 Namespaces

default namespace rss = "http://purl.org/net/rss1.1#"
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
namespace NoNS = ""

Syntax: The RSS 1.1 and RDF namespaces must be declared on the root element of each RSS 1.1 document. The RSS 1.1 namespace is "http://purl.org/net/rss1.1#" and the RDF namespace is "http://www.w3.org/1999/02/22-rdf-syntax-ns#".

4.2 xml:base Attribute

AttrXMLBase = xml:base { xsd:anyURI }

This sub-section is normative. Every xml:base attribute used in an instance document affects the following values in each of its child nodes:

rdf:about attribute values
rdf:resource attribute values
the values of any attribute value or element content whose value must be an instance of the XSD anyURI datatype according to the normative schema in section 6.

Processors should resolve all of the URIs given above against the closest ancestor xml:base attribute value as though it were the base URI of the document itself.

4.3 <Channel> Element (document root)

start = Channel

Channel = element Channel { Channel.content }

Channel.content = ( 
   AttrXMLLang?, AttrXMLBase?, AttrRDFAbout,
   (title & link & description & image? & Any* & items)
)

Any = element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*,
   mixed { Any* }
)

AttrXMLLang = attribute xml:lang { xsd:language }
AttrXMLBase = attribute xml:base { xsd:anyURI }
AttrRDFAbout = attribute rdf:about { xsd:anyURI }

Syntax: The Channel element is the root element of an RSS 1.1 document, upon which the namespaces given in section 4.1 must be declared. The Channel element must have an rdf:about attribute, the value of which must be an instance of the XSD anyURI datatype. Optionally, it may have an xml:lang attribute, the value of which must be an instance of the XSD language datatype, and an xml:base attribute, the value of which must be an instance of the XSD anyURI datatype. The content of the Channel element must be a sequence of title element, link element, description element, optional image element, zero or more elements defined in the Any section, and items element, in any order.

Usage notes: The rdf:about attribute provides the URI that identifies the channel. It must not be the same as any of the URIs used for any of the other things in an RSS 1.1 document, e.g. Items and Images. The URI identifying a channel is often that used for either the homepage of the content provider, or for the feed itself.

Users should note that transclusion of XML fragments nested within the Channel, e.g. using XSLT's document() function, will not be resolved against the value of the xml:base attribute.

4.4 <title> Element

title = element title { title.content }

title.content = ( 
   AttrXMLLang?, text
)

AttrXMLLang = attribute xml:lang { xsd:language }

Syntax: The title element may optionally have an xml:lang attribute, the value of which must be an instance of the XSD language datatype. The title element's content must be text.

Semantics: This provides the human readable title for Channels, Images, and Items. It is synonymous with the Dublin Core title element, and XHTML's title element.

Usage notes: An aggregator may want to map, for example, a Channel's title element onto xhtml:title, an Image's title element onto xhtml:img/@alt, and an Item's title element onto xhtml:h2.

4.5 <link> Element

link = element link { link.content }

link.content = ( xsd:anyURI )

Syntax: The link element must have as its content text that is an an instance of the XSD anyURI datatype.

Usage notes: When used as a child of the Channel or image elements, the value of link is usually, but not always, the same as Channel's rdf:about attribute. Note that it is the url element that provides a source for an image, not the link element. When used as the child of an item element, the value of link is usually, but not always, the same as the item's rdf:about attribute, if it is present.

4.6 <description> Element

description = element description { description.content }

description.content = ( 
   AttrXMLLang?, text
)

AttrXMLLang = attribute xml:lang { xsd:language }

Syntax: The description element may optionally have an xml:lang attribute, the value of which must be an instance of the XSD language datatype. The description element's content must be text.

Usage notes: Users should be aware that conformant User-Agents are required, per section 7, to not interpret the content of this element as encoded HTML; viz. "this is a description" is not to be converted to "this is a description" by the client. Users should instead make use of the RSS 1.1 Payload Module, which offers the ability to annotate items with well-formed XHTML.

4.7 <image> Element

image = element image { image.content }

image.content = ( 
   AttrXMLLang?, AttrRDFResource, 
   (title & link? & url & Any*)
)

Any = element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*,
   mixed { Any* }
)

AttrXMLLang = attribute xml:lang { xsd:language }
AttrRDFResource = attribute rdf:parseType { "Resource" }

Syntax: The image element must have an rdf:parseType attribute with its value set to "Resource", and may optionally have an xml:lang attribute the value of which must be an instance of the XSD language datatype. The image element's content must be a sequence of title element, optional link element, url element, and zero or more elements defined in the Any section, in any order.

4.8 <url> Element

url = element url { url.content }

url.content = ( xsd:anyURI )

Syntax: The url element must have as its content text that is an instance of the XSD anyURI datatype.

Semantics: The value of this element is the URI of the image itself. Note that this is distinct from the link element, which is to be the URI of the Channel, and not the image.

4.9 <items> Element

items = element items { items.content }

items.content = ( 
   AttrXMLLang?, AttrRDFCollection,
   item*
)

AttrXMLLang = attribute xml:lang { xsd:language }
AttrRDFCollection = attribute rdf:parseType { "Collection" }

Syntax: The items element must have an rdf:parseType attribute with a value of "Collection", and may optionally have an xml:lang attribute the value of which must be an instance of the XSD language datatype. The items element must have as its content zero or more instances of the item element.

Semantics: The items element is the relationship between a Channel instance and an ordered collection of item instances, i.e. associating a list of items with a particular channel. Though the order of the child elements is significant, user agents may instead want to order items based on other attributes such as last modified dates provided by an extension module.

4.10 <item> Element

item = element item { item.content }

item.content = ( 
   AttrXMLLang?, AttrRDFAbout,
   (title & link & description? & image? & Any*)
)

Any = element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*,
   mixed { Any* }
)

AttrXMLLang = attribute xml:lang { xsd:language }
AttrRDFAbout = attribute rdf:about { xsd:anyURI }

Syntax: The item element must have an rdf:about attribute the value of which must be an instance of the XSD anyURI, and optionally an xml:lang attribute the value of which must be an instance of the XSD language datatype. The content of the item element must be a sequence of title element, link element, optionally a description element, and zero or more elements defined in the Any section, in any order.

Semantics: The value of the rdf:about attribute must uniquely identify the item. An item is a discrete content instance, the exact nature of which is up to the provider: examples include weblog posts, recipies, sports events, news items, and specification updates.

Usage notes: The value of each rdf:about attribute must be unique to the document, per [CC5-RDFABOUT]. This is to ensure that there are no duplicate items in the resulting RDF graph, and hence that items are not merged together. Since the rdf:about attribute is optional on the item element, content producers that cannot ensure the production of unique rdf:about values should omit the attribute altogether. Technically, the unique value will then be generated by an RDF parser in the form of a blank node. This constraint also ensures that channels do not appear within themselves, and that there is no conflation of channels and items.

The value of rdf:about should be a unique identifier for the item. If two items have the same rdf:about, they should be considered the same by User-Agents. Content producers should thus ensure that the value is unique: for example, a site being reviewed in a weblog entry should not have the URI being reviewed as an rdf:about; it should use the <link> field for this purpose instead. The value of rdf:about in such a case might be a weblog-local unique identifier, perhaps based on an entry identifier. In cases where the URI of the blog entry is unique, this can be used as both an identifier and as the <link> field.

4.11 Any

Any = element * - ( rss:* ) { Any.content }

Any.content = ( 
   attribute * - ( rss:* | NoNS:* ) { text }*,
   mixed { Any* }
)

Syntax: Any number of elements from outside the RSS namespace, with any number of attributes from a namespace outside the RSS namespace, and with mixed content of the same (recursively). Per [CC4-RDF] the root of every Any section, viz. those which are not nested inside an Any section, must be a conforming instance of the propertyElt production of section 7.2.14 of the RDF/XML Syntax Specification.

Usage notes: The Any sections constitute the syntactic placeholder for RSS 1.1's extensibility. That is to say that any extra elements may be used here as long as the conformance requirements are met, including compatible RSS 1.0 modules. Note that Any sections may only occur as siblings in their parent element, so for example core RSS 1.1 elements must not be nested in between Any sections; see the list of changes for further details.

5. RELAX NG Compact Schema

The following is the normative schema for RSS 1.1 using the RELAX NG Compact format:

6. Turtle RDF Schema & OWL Ontology

The normative RDF Schema for RSS 1.1, including OWL information making it an OWL Lite ontology, is available from: ont.rdf

The following is a non-normative alternative version of the same RDF Schema/OWL ontology using the Turtle serialization of RDF:

7. User-Agent Conformance

This section is normative. A conformant User-Agent is one that adheres to all of the requirements in this section.

Usage notes: User agents MUST NOT interpret the content of the description element as encoded HTML; viz. "this is a description" is not to be converted to "this is a description" by the client. The RSS 1.1 Payload Module enables users instead to annotate their items with well-formed XHTML markup, and therefore SHOULD be supported by User-Agents.

7.1 User-Agent Error Recovery

Appendix A: References

Appendix B: Errata

Upon official release, the only changes made to this document shall be to correct mistakes and resolve ambiguities in the specification; no structural or semantic change, even to the smallest degree, shall be made. All corrections made to the document shall be recorded in this appendix, with a link to a diff of the change.

Draft Changes

The following is a list of changes implemented between the current version of this specification and the previous 2005-01-17 draft:

Appendix C: Changes From RSS 1.0

Appendix D: Mapping from RSS 1.0 to RSS 1.1

This section is non-normative. The following is a file in the Turtle serialization of RDF containing OWL information that makes the following an OWL Full document:

This document is also available as the following non-normative standalone files:

A non-normative XSLT mapping from RSS 1.0 to RSS 1.0 is also available: rss1to1.1.xsl

Appendix E: Backwards Compatibility

The following backwards compatibility recommendations are brought forward from the RSS 1.0 specification, which mandated them in order that RSS 1.0 be backwards compatible with RSS 0.9x tools. They are noted here because although RSS libraries have advanced to a point where these recommendations are less important, in practice it's possible though unlikely that old RSS 0.9x tools updated to parse RSS 1.0 and 1.1 may still contain bugs based around them. Therefore, for maximum backwards compatibility, the following recommendations should be heeded:

Appendix F: Acknowledgements

Note: Acknowledgement of contribution does not imply endorsement of this work.

Thanks to Cody Woodard for early review comments, architectural suggestions, and the logo; to Joe Geldart for comments on the OWL species of the RSS 1.1 ontology; and to Ken MacLeod, Ian Davis, and other rss-dev participants for a range of helpful review comments.

RSS would not have been possible without the early efforts of Netscape Communications Corporation, and UserLand Software, Inc. The RSS 1.1 specification is a furthering of that carried out by the RSS-Dev Working Group; the authors of the RSS 1.0 specification. They are as follows:

RSS 1.1: RDF Site Summary

Preliminary Draft: 23rd January 2005

Abstract