Moving RSS Forward with an XRSS Namespace

The Really Simple Syndication format contains only five required elements -- rss, channel, title, link and description -- and either a title or description in each item. Everything else is optional.

One way to tackle confusing aspects of RSS is by defining a new namespace, XRSS, with replacements for all of the optional elements.

The XRSS spec could document the namespaced elements and also offer advice for the required RSS elements. To show how this would work in practice, I've created an XRSS namespace spec and a sample file.

The Harvard spec is the authority over all required RSS elements described in the XRSS spec, as stated in the Elements introduction:

An XRSS document consists of five required RSS elements, two required RSS elements for each item and zero or more optional XRSS elements.
The definitions of the RSS elements in this specification are provided for convenience and MUST NOT be treated as definitive. Refer to the RSS 2.0 specification for authorititive guidance on the format.
All elements of an XRSS document that are not contained in a namespace MUST be described in this specification. All recommendations offered for RSS elements in this specification SHOULD be followed in XRSS documents."

RSS documents that use the XRSS namespace would be declared in the rss element:

Any document with such a declaration indicates that it follows the XRSS spec, its definition for XRSS elements, and has reviewed the best-practice recommendations for RSS elements.

All namespaced elements would be under the clear authority of the XRSS spec, removing the need to mirror the behavior of the similarly named elements in RSS.

For instance, the enclosure element could be defined so that "an item may contain more than one enclosure."

Another problem the namespace can solve is whether to use an item's link or guid when the latter is a permalink:

A publisher should provide a guid with each item. When a guid represents a permalink, it should take precedence over the item's link.

The namespace also could drop elements that serve no discernible useful purpose and are rarely implemented, such as textInput.

This would indisputably follow the RSS roadmap:

Subsequent work should happen in modules, using namespaces ...

Rss · 2006/03/07 · 6 COMMENTS · Link

Comments

Rogers,

Do you have a workspace to discuss XRSS? Is this coming out of the RSS Advisory Board, or is this a personal effort?

- M

#1 · Mark Woodman · 2006/03/07

Woops, found the answer in the spec intro:

Public comments on this proposed specification, which is still in active development and has not been officially adopted by the RSS Advisory Board or any other group, are welcomed on the mailing list RSS-Public.

#2 · Mark Woodman · 2006/03/07

Yep. If XRSS passes from proof of concept stage to active development, it'll take place on RSS-Public.

#3 · Rogers Cadenhead · 2006/03/07

Rogers: My hat is off to you for pushing forward here, but I think XRSS might be more trouble than it's worth.

I mean, why create a new extension to clean things up when you can just use Atom elements within RSS instead? They're already spec'd, after all.

#4 · Roger Benningfield · 2006/03/08

Does this mean that you would expect RSS readers to be able to handle the "xrss:" prefix on all valid RSS elements? If so, I think Sage might be broken by that. I found this in the sageRSSReader.js file:

for (i = 0; itemNodes.length > i; i++) {
if (itemNodes[i].prefix) continue; // skip elements with namespaces

#5 · Sterling Camden · 2006/03/13

I dont sure about target of XRSS? Whats benefit it bring?

#6 · Alexei A. Korolev · 2006/03/16