RSS Core Profile DRAFT 1

| No Comments | No TrackBacks

UPDATE: A second draft has been published here.

This is a slightly more formalized write-up of a proposed profile for RSS that has been discussed and brought up again. Rather then just produce an iteration of what Don Box wrote up, I thought I'd take a step back to codify some of the design considerations in which other profiles may be built. I believe with this established going forward will be much smoother and better focused.

While we may not be able or want to identify them right now, there will be different profiles depending on the context. A comments feed will have different requirements then a news/weblog feed that will have different requirements then an embedded item in an API message. While these contexts and their needs will certainly vary, they needn't be entirely different. The Core Profile is an attempt to create a foundation that other profiles, such as "RSS for Weblogs," can be derived.

UPDATE: Sam Ruby has opened a comments area on on this post. Please direct any feedback on this draft there.

RSS Core Profile

DRAFT 1

ABSTRACT

The RSS Core profile defines a restricted subset of existing RSS formats that balances ease of use and authoring with ease of consumption by applications while maintaining the richness necessary to extended and adapt to various problem domains. It is designed for authors wishing to provide a well-formed "feed" of information to consumers. It is designed to provide a foundation for other more focused profiles to be based on.

The RSS Core profile is designed around a simple core of elements that may be easily extended through namespaces and modules. It is also designed to maximize backward compatibility with the RSS 0.91 format and its descendents. This allows the profile and derivitives to leverage the existing install base of 0.91 feeds and prior bodies of work such as Dublin Core meta data and RSS 1.0 modules.

The goal of the RSS profile is to serve as guidelines to best practices in a balanced and simplified approach to authoring and consuming of resources with RSS.

COMMON CORE TAGS

<rss>
Description: The root tag for the syndicated resources collection.
Sub-Elements: channel (required)
Attributes: version - a string identifying the version including profile and document type.
Notes: Only one channel is permitted.

<channel>
Description: Container tag for a specific channel
Sub-Elements: title (required), description (required), link (required), item (required)
Attributes: none.
Notes: Only one title, description or link is permitted. Language is depreciated.

<item>
Description: Container tag whose contents represents one resource in the channel. At least one item must be present in a channel.
Sub-Elements: title (required), link (required), description (optional but highly recommended)
Attributes: none.
Notes: Recommended to not exceed 15 per channel.

<link>
Description: A unique URI using a IANA-registered scheme that specifies the location of the channel or item (resource). Applications are required only to support one of any of these IANA URI schemes however http:// is highly recommended. A required sub-element of channel and item.
Sub-Elements: none.
Attributes: none.

<description>
Description: A plain text excerpt of the channel or item (resource). A required sub-element of channel. Optional, though highly recommended, sub-element of item.
Sub-Elements: none.
Attributes: none.
Notes: The RSS Core profile supports plain text and does not permit encoded markup such as HTML to be included in the description. Recommended not to exceed 500 characters. Those wishing to embed markup language or larger pieces of content in the description tag should use the mod_content module.

<title>
Description: A plain text descriptive title of the channel or item (resource).
Sub-Elements: none.
Attributes: none.
Notes: Is the equivalent of the HTML title and only supports plain text. Encoded markup such as HTML is not permitted to be included in the title. Recommended to be no more then 100 characters.

DEPRECIATED TAGS

Tags not defined other tags from RSS 0.91 and its descendents are considered depreciated from the core in the RSS core profile. This data can be furnished though various modules such as Dublin Core, mod_content and mod_admin. All depreciated tags in the RSS core profile where previously considered optional except language which was required by the 0.91 specification, but made optional in later specifications.

TAG MAPPING

As it exists today, most tags that would be considered deprecaited by this profile, have a modulized equivelant. The following is an an initial mapping of tags for those who opt to comply with this profile.

  • language: dc:language (see footnote in outstanding issues.)
  • copyright: dc:rights
  • lastBuildDate: dcterms:modified matching HTTP 1.1 Last Modified.
  • managingEditor: dc:publisher
  • pubDate: dc:date
  • guid: link (links should be unique URI.)
  • webMaster: admin:errorReportsTo
  • category: dc:subject
  • expirationDate: dcterms:valid
  • generator: admin:generatorAgent
  • cloud: cp:server
  • rating: rss091:rating
  • source: dc:source or ag:source & ag:sourceURL
  • skipDays & skipHours: rss091:skipDays or rss091:skipHours or use mod_syndication for more advanced functionality.
  • enclosure: mod_image, mod_audio or mod_streaming dependinng.
  • ttl: similar functionality is in mod_syndication
  • docs: annotate:reference (Or should this be the namespace URI?)
  • comments: annotate:reference
  • image: see mod_image (Though mod_image is designed to work with and suppliment the existing image tags from RSS0.91 from what I can tell. The conversation trailed off and never completed. Jon Hanna has proposed another specification that I thought wasn't as good as Kevin Burton's mod_image. http://www.benhammersley.com/archives/003096.html.)
  • textinput: (Needs to be addressed. RSS 1.0 allows it so no module has been designed to date. annotate:reference helps provide a link, however its an empty tag that you couldn't insert a dc:title or other tags.)

EXTENSIBILITY

Without detailed information to extending RSS 2.0 with modules and XML namespaces, the RSS Core Profile will follow the guidelines set forth in the RSS 1.0 format module documentation. Modules should make every attempt to keep module syntax streamlined and simple by minimizing the use of RDF/XML constructs.

EXAMPLES

OUTSTANDING ISSUES

  • How to identify the profile/document type? Place in version? or use XML document type? Both?
  • link tag language sufficient? http:// is highly recommended or should it be required?
  • Need to better address non-English language feeds. Morten Frederiksen suggests inclusion of a clause like "if the language is not English, please include the dc:language element according to XXX." Should non-English feeds be forced to use Extensible or Transitional? Is there a better way?
  • RSS 2.0 can never use a default namespace?

CHANGE LOG

DRAFT 1, Jun 03 2003

No TrackBacks

TrackBack URL: http://appnel.com/mt/pings/108

TITLE: RSS Core Profile URL: http://www.intertwingly.net/blog/1446.html IP: 209.61.183.90 BLOG NAME: Sam Ruby DATE: 06/03/2003 12:08:13 PM Read More

RSS Profile from techno weenie on June 3, 2003 2:14 PM

RSS Core Profile DRAFT 1. Read More

RSS Core Profile DRAFT 1 from anil dash's daily links on June 4, 2003 6:34 AM

http://www.mplode.com/tima/archives/000290.html... Read More

Leave a comment

About this Entry

This page contains a single entry by Timothy Appnel published on June 3, 2003 9:10 AM.

SOAP/RSS is simpler then you may think. was the previous entry in this blog.

RSS Core Profile DRAFT 2 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 4.2rc2-en