Our welcome from (and to) the community

Well, this is has been quite a fun 30 hours. Yesterday, at Gnomedex 5.0 Dean, GM of the Browsing and RSS Technologies team (and frequent IEBlog poster), announced a bunch of RSS-related features of Longhorn. Details of all that are on the MSDN site.

The other main thing that Dean talked about is our interest in helping to bring the concept of "lists" to RSS, since we see an amazing amount of user value in doing so. To help move that along, we posted a proposal on how to do this that contains the main features we think are important about lists.

(a) A way for the publisher to indicate to a client that the feed is a list. Consumers should then process the list in a slightly different way from normal feeds.  

In the specification, we used a feed-level element called "cf:treatAs", with the value of "list" ("cf" represents the namespace we're using for these extensions -- it's defined in the specification).

(b) A way for the publusher to indicate to a client which of the elements on the items in the feed are interesting for the client to expose to the user for sorting and pivoting.
In the spec, we used a set of elements at the feed level which are structured like so:

<cf:listinfo>
<cf:sort>
<element data-type="date|text|number">
User-readable name for the element
</element>
</cf:sort>
<cf:group>
<element>
User-readable name for the group.
</element>
</cf:group>
</cf:listinfo>

Well, we've been hearing a lot of great feedback about these lists, including Phil Ringnalda's comments which point out some concerns that he has with the way the spec re-uses element names which are technically defined in someone else's namespace.

In Phil's comments, Matthew Gertner, and Tim Bray suggest a different structure, which I'll reproduce here:

<cf:listinfo>
<cf:sort name="element" ns="namespace" data-type="date|text|number">
User-readable name for the element
</cf:sort>
<cf:group name="element" ns="namespace">
User-readable name for the group
</cf:group>
</cf:listinfo>

I think this is better. It still keeps the basic idea of helping the consuming app to present useful information to its clients, and its easier for people to parse.

So... what do people think? This is an easy change to make, and if the community is in favour, I will make change the spec to this format.

- Sean