I mentioned last week that currently with traditional portal sites like MyMSN or MyYahoo, I can customize my data sources by subscribing to RSS feeds but not how they look. Instead all my RSS feeds always look like a list of headlines. Start.com fundamentally changes this model by turning it on its head. I can create an RSS feed and specify how it should render in Start.com using JavaScript in extension elements which basically makes it a Start.com gadget, no different from the default ones provided by the site. For example, I can create an RSS feed for weekly weather reports and specify that they should rendered as shown below within Start.com

Scott Isaacs gives some descriptions of how the RSS extensions used by Start.com work in his post Declaring Gadgets for Start.com using "RSS". He writes

Introduction to the Gadget Manifest

First, let's look at the Gadget manifest format. For defining manifests, we basically reused the RSS schema.  This format decision was driven by the fact we already have a parser in Start.com's application model for RSS, there is broad familiarity with the RSS format, and I personally did not want to invent yet another schema . While we reused the RSS schema, we do recognize that these are not typical RSS feeds as they are not intended to be consumed and directly rendered by an aggregator. Therefore, we are considering whether we should use a different file extension or root element (e.g., replace RSS with Manifest) but still leverage the familiar tags. For the sake of simplicity, we chose to ship reusing RSS as the format and then listen to the community on how to proceed. We are very open to suggestions.

Looking at the Gadget manifest, we extended the RSS schema with one custom tag, and one custom attribute. We defined those under the binding namespace. Below is a sample Gadget manifest:

<?xml version="1.0"?>
<rss version="2.0" xmlns:binding=" http://www.start.com ">
   <channel>
      <title>Derived Hello World</title>
      <link>http://yourhomepage.com</link>
      <description>A sample hello world binding.</description>
      <language>en-us</language>
      <pubDate>Wed, 27 Apr 2005 04:00:00 GMT</pubDate>
      <lastBuildDate>Wed, 27 Apr 2005 04:00:00 GMT</lastBuildDate>
      <binding:type>Demo.MyHelloWorld</binding:type>
      <item>
         <link>http://siteexperts.com/bindings/MyHello.js</link>
      </item>
      <item>
         <link binding:type="inherit">http://siteexperts.com/bindings/hello.xml</link>
      </item>
      <item>
         <link binding:type="css">http://siteexperts.com/bindings/myHelloWorld.css</link>
      </item>
   </channel>
</rss>

Looking at the Gadget manifest, until we reach an RSS item, the semantics of the existed RSS tags is maintained. The title serves as the Gadget title, link typically points to your home page or page about your Gadgets, description is your Gadget's description, and so on.  The added binding:type element serves as the Gadget class to instantiate from the associated resources.

Looking at each item, we do know that we left off the required title and description since this file is not intended to be directly viewed. However, adding those tags could be useful to help describe the resources being used.

The last change is we added a binding:type attribute to each resource. We currently support three types: script (the default), css, and inherit. Inherit would point to another "RSS" manifest file that would be further consumed.

Assocating a Manifest with a Feed

Start.com supports loading stand-alone Gadgets directly from a manifest. In addition, You can now define a Gadget that presents a custom experience your feed. This is very useful for a number of scenarios...The custom experiences are defined using the "RSS" Manifest format described above. However, since these Gadgets for RSS feeds are driven by the feed itself, we needed to extend traditional RSS with a single extension. This extension associates a manifest with the feed. We created a new channel element, binding:manifest that can be included in any RSS feed. This element specifies the Gadget manifest to use for the feed.

<binding:manifest environment="Start" version="1.0">
  http://siteexperts.com/bindings/rumorcity.xml
</binding:manifest>

We created this element to not be coupled to any single implementation. Hence the required environment element. Aggregators that understand the manifest tag can examine the environment value. If they support the specified environment, they can choose to present the custom experience.

Despite the fact that I kicked off some of the initial discussions with Steve Rider for what are now Start.com gadgets, I haven't paid much attention to the design since Start.com is a work in progress. Based on the current design, I have two primary pieces of feedback.

1. I'd suggest picking a different namespace URI. XML namespace URIs usually point to documentation about the format, in the cases that they don't it is often a cause of consternation amongst developers. For example, most XML namespaces used by Microsoft are from the schemas.microsoft.com domain which often point to schemas for the various Microsoft XML vocabularies. In the cases where they don't it is likely that they will in future. See http://www.google.com/search?q=+site:schemas.microsoft.com+%22schemas.microsoft.com%22 for some examples.

2. If Gadget manifests aren't supposed to be consumed by traditional RSS aggregators then Start.com should not use RSS as it's manifest format. The value of using RSS is that even if a client doesn't understand your extensions then the feed is still useful. Start.com currently breaks that assumption which to me is an abuse of RSS.
   

Scott is currently seeking feedback for the Start.com RSS extensions and I'd suggest that interested parties should post some comments about what they like or dislike so far in response to his blog post.

Update: Since writing this post I've exchanged some mail with the Start.com team and in addition to my feedback we've discussed feedback from folks like Phil Ringnalda and James Snell. The Start.com team used RSS as the gadget manifest file format as an experiment in the spirit of the continuous experiment that is http://www.start.com. Based on the feedback from the community, alternatives will be considered and fully documented when the choices have been made. Given my experience in XML syndication technologies I'll be working with the Start.com team on exploring alternatives to the current techniques used for creating gadget manifests as well as documenting them.

Keep the feedback coming.