UPDATE: To hopefully clear up some confusion, I added a slight clarification on the manifest introduction.

The following should get cleaned up, expanded, and posted to the Start.com/developer site some time next week. The past week I have been posting samples and details on creating Gadgets. I wanted to get more detailed documentation on creating the necessary Gadget manifests and associating Gadget manifests with RSS feeds posted as quickly as possible.

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.

UPDATE: In case I wasn't clear, the manifest format is a stand-alone file (you do not intersperse resources with your existing RSS feed items). We will be moving away from the RSS moniker as we know this is confusing. The only extension we are proposing to be included in existing feeds is the binding:manifest tag explained below.

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. First, consider the RSS extensions being proposed: how do you provide a relevant experience for Open Search, List, and any future extension without redeploying new aggreagtors. Furthermore, some RSS feeds may be better represented by a custom experience (e.g, daily horoscopes).  Basically, while content representation is universal, why should the experience be? I would not be surprised to see extensions for geo-coordinates, and so on. When that occurs you will probably want to integrate a map, etc., into the experience.

With Gadgets for Start.com, you can associate your feed with any custom experience. You can develop your own, subclass or consume another experience on the web, or choose (soon) from a set of experiences on Start.com. When your feed loads in Start.com, if it is associated with a custom Gadget, the user is presented the option to use the custom experience or default to the traditional list-view (they can also swich between views so you don't have to worry about being trapped into a "bad" experience :-).

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.

Just like our RSS manifest above, we chose a simple and straightforward solution to answering the following question:

How does a feed associate itself with a custom experience?

Again, just as with the manifest format, we are open to suggestions that help us answer that question. 

Last, I suggest examining the samples on http://www.start.com/developer and my earlier blog entires to see how you manipulate the feed from within your Gadget.

Be sure to send any feedback or pointers to any Gadgets you create to Start.com.