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:

        <element data-type="date|text|number">
            User-readable name for the element
         User-readable name for the group.

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:sort name="element" ns="namespace" data-type="date|text|number">
      User-readable name for the element

   <cf:group name="element" ns="namespace">
      User-readable name for the group


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

Comments (38)

  1. The one thing that worries me (well, that’s a tiny risk of misinterpretation) is when a publisher is using a core RSS 2.0 element for sorting or grouping: cf:element="title" cf:namespace="" should mean the title element in no namespace, thus the RSS 2.0 title element, but I’d be less nervous about someone down the line interpreting that as being the title element in the current default namespace if the spec either said outright that it isn’t that, or even just forbade cf:namespace="", requiring that the attribute must not be present unless its value is the URI for a declared namespace (and explicitly requiring it be a declared namespace helps out the Feed Validator, letting it tag typos in cf:namespace URIs as errors, not just warnings).

    (Okay, the second thing that worries me is that I think your attributes ought to be namespaced as well, but I don’t keep track of XML specs and TAG findings well enough to point at anything that says so, and the third thing that worries me is that I still don’t understand what you mean by "group" as distinct from "sort," but I’ll work that out eventually.)

  2. James Snell says:

    The change looks good. I definitely concur with Phil that you’re going to run into issues with @namespace="". Requiring that the namespace attribute be omitted when the element does not exist within a namespace (as with the RSS 2.0 elements) is definitely a possible solution.

    Another thought that struck me as I was looking this over. I’d be really hesitant to add any level of complexity to this, but I could see a need for the content producer to be able to specify a default sort order. For example, support I want the list to be sorted in reverse by date?


    &lt;cf:sort name="pubDate" data-type="date" order="desc" default="true" /&gt;

    …where only one cf:sort in listinfo is allowed to have @default="true" and the value of @order is "desc" or "asc".

  3. This looks like a good change to me.

  4. Sam Ruby says:

    Why not simply alow the cf:sort and cf:group elements to be placed at the feed level?

  5. Don Park says:

    I like the change and the suggestions made above as well.

  6. Sean: Definitely a positive change. Although honestly, I’m still partial toward something like:


    [title cf:data-type="text"]my title[/title]

    [dc:date cf:data-type="date"]2005-03-01[/dc:date]


    Just seems like that would result in the least confusion over the long haul, and maximize the flexibility. Although in all fairness, like Phil, I don’t understand what "group" does, so maybe I’m totally off-base.

    But again, as-is, the proposed changes are great.

  7. Danny says:

    This looks a definite improvement over the previous version, but I’m still not sure about the general approach.

    First off: what are the items in the list? Right now it seems to be the entries in the feed. But might it not be useful to include list structures within entries – for example a set of podcasts of different quality. So I’d consider using node identifiers to point to the individual things that can be sorted rather than the element names. Why just sortable lists – what about unordered lists (Bag) and one-of options (Alt).

    Sort order ascending or descending?

    What about the language of the user-readable name?

    There’s significant previous work with RSS 1.0 having supported lists (trees, tables etc) since its inception thanks to RDF. If I personally was putting together a list extension for RSS I’d start by looking at RDF because of this. Additionally RSS 1.0 has the best-defined extension mechanisms around 1.0/2.0/Atom. RDF makes it easy to add extra information about any resources being described (such as sort order or datatype), as that’s exactly what it was designed for. Have you considered how your extension will interact with other extensions – comments, CC, Media RSS, microformats, FOAF? If you have an RDF-based model, you get a consistent approach to merging multi-namespace material for free.

    Only after having a convincing model would I look at the syntax, starting with RDF/XML for RSS 1.0. That should be relatively straightforward to transpose into Atom, as that has a reasonably well defined extension structure. Only then would I contemplate how it looks in RSS 2.0, which has the loosest extension mechanism (anything can go anywhere as long as it’s namespaced). You’re making life harder than it needs to be by targeting RSS 2.0 first. It would have supported lists already had it not been "simplified".

    I suggest you check out rdf:Seq, rdf:Collection, rdf:datatype and rdfs:label –


  8. paul says:

    If RSS 2.0 is so wonderful why do we need to change it?

    It’s time to change formats and dance with ATOM 1.0

  9. Danny says:

    Just as an aside, you might find this interesting. It’s a description of the early days (and plans) of RSS by Dan Libby, lead author of RSS 0.9 and RSS 0.91 :


  10. I wrote a little note to you guys about what I think you can improve with your demos.


    Love the idea though. Keep up the good work and keep trying to get those other Microsoft teams to jump onboard the RSS train.

  11. Steve says:

    First off, very cool stuff! Can’t wait to play with this in the Longhorn Betas…

    I’d also agree with Phil’s comments around the namespace issues with the original format so keeping all of this metadata in its own namespace seems like the right thing to do. My questions are primarily around the grouping constructs. As several others have asked, what is it that you intend here? Are you trying to let publishers control what columns can be grouped by? Assuming that’s the case here are my comments:

    – What does “User-readable name for the group” mean? In most grouping UI’s I’ve seen the group title is the actual contents of the field that was grouped by or some other value like “today|yesterday|last month” for date range buckets. So I’m not sure what the UI would be expected to show here.

    – How does the UI know what algorithm to employ when breaking items into groups? From my experience you need to know two things, the data type of the column being grouped on and the algorithm to apply. In most cases you can infer the algorithm to use from the data type but some data types can support multiple algorithms. For instance if the column is a text should the UI group items by unique values or into alphabetical buckets?

    – I’m not sure why you need to separate out the grouping definition from the sorting definition. I’m assuming you did this so the publisher can define sortable and groupable elements independently of one another. But as I pointed out above the UI needs common information about an element to accomplish both tasks.

    Here’s another way to define a feeds list metadata that I think is a little less ambiguous for the UI developer:


    <cf:column name=”element” ns=”namespace” data-type=”date|text|number” sort=”none|ascending|descending” group=”none|value|alpha|count|date|size” default=”true|fale”>

    User-readable name for the column



    This schema takes a slightly different approach then the proposed schema in that its really about identifying what elements within the feed are list columns and then providing the additional metadata the UI needs to know how to deal with those columns. The sort & group attributes allow for the enabling/disabling of those features independently on a per column basis. The ascending & descending values let you author the initial sort order to use when a user selects a given column and the various grouping algorithms are common ones I’ve identified across the Shell, Outlook, and various other apps. The default attribute lets the publisher call out the preferred initial column to group or sort by.

  12. r_n says:

    just wanted to point out that it took me some work to find the rss feed for this site. that text atop is badly coloured. how about an orange xml button?

  13. BigJimInDC says:

    I can only hope that someone grabs this spec and creates a solution that allows me to share a single contacts list amongst all of the web sites that utilize contact information. Or better yet, allows for distributed creation, editing, deleting of contacting information and the subsiquent n-way synchronization of those changes amongst all participating systems.

    What I’m talking about is the fact that my current master list of contacts is in my corporate MS Exchange Contacts folder. That gets sync’d to my smartphone, pocketpc, etc. But it doesn’t seamlessly make it into Hotmail, Evite, MS Outlook Express, Eudora, and the rest of the online and offline systems that I use that also utilize contact information.

    Anyway, for as cool as having the list of 400+ DVD’s and 700+ CD’s that I own accesible via an RSS style list would be, having my contacts accessible in that manner would be an order of magnitude more useful. Please, someone somewhere make this the first sample application of RSS Lists support so that I can utilize it sooner than later!

  14. I’d second Danny in terms of using portions of RDF to represent list (or at least keeping elements relatively consistent with it) but I don’t think that trying to go back to RSS 1.0 makes sense. In fact, rdf:Seq seems to fullfill the same purpose as cf:sort but ads the value of treating each element as rdf:li

  15. Say you have a feed of "Our 50 top selling books," a use-case that’s just what they are aiming at. You feel it might be useful to a user to be able to sort on title, bs:author, bs:price, bs:publicationdate, bs:availability, category, and bs:audience. Using cf:sort, you add eight elements, using rdf:Seq you add, what, 366? Why would anyone want to introduce the single most hated part of RSS 1.0, the items Seq, to RSS 2.0 and Atom?

  16. Danny says:

    On a more general point, I reckon it would probably make sense to separate out the grouping, datatypes and sort order. The feed would contain details of the grouping of elements, where you want to sort on a specific datatype include that as the rdf:datatype of the element in question.

    Leave decisions on how to do the sorting to the tool reading the data, i.e. separate data from presentation.

    But I take your point about Seq, that probably would be a poor way of doing it with the example you give. Why are you expressing the sortable data type as well as the specific sort order? Won’t the data type + values provide enough info for the order?

    Probably the easiest all round in RDF would be to use simple (RDFS) typing for the grouping and rdf:datatype to give the datatypes of the individual elements.

    Given that RDF/XML already has the talking-about-element-names thing built in, it might be easier to follow a general structure like that of the proposed syntax, but expressed in the RDF model.

    How about something like this:

    &lt;item rdf:about="http://amazon.com/coolbook&quot;&gt;”>http://amazon.com/coolbook&quot;&gt;

    &lt;title&gt;One Cool Book&lt;/title&gt; &lt;dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date"&gt;2005-06-28T01:45:00Z&lt;/dc:date&gt;

    &lt;bs:price rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">3.50</bs:price&gt;


    &lt;bs:Book rdf:about="http://amazon.com/coolbook&quot; /&gt;

    That last line adds that as well as being an rss:item, the thing in question is also a bs:Book. That (or something similar) could provide the grouping.

    Then if you were using SPARQL (SPARQL Protocol and RDF Query Language) your example could be accessed something like this:

    SELECT ?title, ?publicationdate WHERE


    ?book rdf:type bs:Book .

    ?book bs:title ?title .

    ?publicationdate bs:date ?date .


    ORDER BY ?date

  17. Shital Shah says:

    I think your current approch may become overly complicated as you move forward. Let’s disect the problem in steps. Your primary goal seems to be allowing custom namespaced elements for data values like this:


    <title>this is required</title>

    <netflix:movieName>Step Into Liquid</netflix:movieName>




    <title>this is required</title>




    The major disadvantage of this scheme is that anyone who wants to publish a list would essentially need to invent their own extention to RSS. Adding a new extention is usually a big change for publishing software as well as consuming software. Even bigger problem is that I could never write a generic list client because list from each publisher lives in its random custom namespace. This means if I have to support lists from different publishers, I would end up writing code in my RSS reader specific to each publisher. As you can see, the tables with custom namespaces like above are simply not practical.

    A far more simpler and flexible approch would be like this:


    <title>this is required</title>




    <cf:value>Step Into Liquid</cf:value>










    Note that publishers don’t have to define their own custom extentions anymore to publish their lists. And now I can very easily write a generic table viewer in seconds. You might also note that I can put many rows in to single item tag which is good because each item tag carries an overhead of title or description tag according to RSS 2.0 spec. Another major benefit is that you can included more information about column value in future and hence your specs are pretty expandable, for instance,






    Further, lot of your problems regarding sorting, grouping and so on could now easily be solved. Remember what you essentially want is to represent tabular data with multiple columns. A column definition could (and would) have several properties besides sorting and grouping:








    An immediate disadvantage of this scheme is that publishers may not include multiple tables in a single feed. I don’t think this should be problem but if it is, you can easily solve by having <cf:table> surround above structures.

    Note that this scheme requires slighly more characters for the same data but could be very easily understood by developers.

    You might also want to check out XML that is generated by DataSet. One valuable optional add-on might be inclusion of relationships. Infect .Net DataSet code may be extended to serialize in to RSS feed instead of usual XML. That would simplify most of developer work right there.

  18. Byron Adams says:

    Been working on this stuff for 3 years before I knew there was a name for it. If you really want to do something great with this that will take it farther than the others, then add in the logic on the server (and client) to communicate a last viewed datetime. With just this simple parameter a client can request the next n items and never miss anything. What good is RSS if I can only get the last n items and miss inbetween n items since my last view and while my system was offline? The server can also save bandwidth by not sending already received items when the end of list is reached. I don’t want to miss RSS items but do because this logic is missing (except on our company intranet site). Can you image only being able to look at the last 10 emails sent to you?

  19. Danny says:

    Let me try that again:

    <item rdf:about="http://amazon.com/coolbook&quot;>”>http://amazon.com/coolbook&quot;>

    <title>One Cool Book</title> <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2005-06-28T01:45:00Z</dc:date&gt;

    <bs:price rdf:datatype="http://www.w3.org/2001/XMLSchema#decimal">3.50</bs:price&gt;


    <bs:Book rdf:about="http://amazon.com/coolbook&quot; />

    In response to Shital: you could do things this way, sure. But there aren’t actually any advantages over using XML names (i.e. named elements in namespaces). You can still build a generic viewer if the details of the "columns" are given using the cf terms, irrespective of the namespace. The disadvantage of putting (column) name/values as text node values is that the data you’re creating is less available for reuse. A direct alternative would be something like:

    (in ‘header’)

    <cf:sortable rdf:about="http://movies.org/ns#MovieName&quot; />

    (in ‘body’)


    This isn’t far from the current proposal.

    Again, if you’re wanting to support arbitrary data models (lists, tables, trees) with XML serialization I’d point to RDF where these problems have already been solved.

    DataSet isn’t a bad pointer, but note that unlike the traditional relational model, the relational model of RDF doesn’t require that you design a fixed schema up front, and is designed for use with resources on the Web – in particular relations are identified with URIs.

  20. So, in my previous post about Microsoft&amp;#8217;s newly announced involvement with RSS, I came to the conclusion that&amp;#8212;at least with respect to the Simple List Extensions&amp;#8212;the happening was more about the delivery than the deftness of the extension itself. And,…

  21. Shital Shah says:

    Danny: RDF and the relational schema that I suggested would accomplish essentially the same purpose. I would care less which poison you choose for yourself. My argument is, however, against the current specs which essentially forces each publisher to create their own RSS extension. In my view, this is a disaster. Also note that current specs has no way to identify these tags in <cf:listinfo> which means each reader MUST add unique code to identify each publisher’s list. With current spec as on MSDN, I fail to see how you can build generic list renderer.

    Even if you tweak <cf:listinfo> to identify these custom tags for list’s data, it would still be pretty messy. A golden rule in any XML design that I follow is to avoid embedding names of namespaces in values of nodes. In other words, if your XML design requires you to write complicated XSLT for rendering, you are probably doing something wrong.

  22. Longhorn Team RSS Blog : Our welcome from (and to) the community: This blog entry on the Microsoft RSS team blog talks about adding lists to RSS. Here’s some of what it says: The other main thing that Dean…

  23. Leigh Dodds says:


    I wasn’t sure where else to address comments on the specification, so I’ve written them up here:


  24. Greetings,

    Is this also the blog of the team that is working on the RSS feed store? The lists extension is interesting, but not earth-shattering. The feed store, and associated downloading issues, is far, far more interesting to me.

    For example, Adam Curry recently announced his intention to go to bittorrent in his enclosures, in order to reduce the $350/day bandwidth costs on his servers.

    Will the feed store natively support bittorrent in order to download streams like that, or will it only support HTTP?

    What about password-protected feeds? IE discontinued the ‘http://username:password@url/‘ format, will the feed store accept it and download from it?

    What about the fact that the data (the feed list and their data) is all locked up in one computer? Will there be an open sharing protocol, that I can connect to from my Windows Laptop, my Powerbook, and my work Linux box, and have my central home Windows box serving as a central feed repository? At the least, subscriptions and unsubs need to be synchronizable…

    I’ve heard rumor there’s some derision in Microsoft towards Attention.XML; I hope that if that’s not the way that you go, at least the way you do go will be as open as the list spec.

    All these are far more interesting questions to me, than implementing lists in RSS 2.0.1+.

    Is this the blog to talk about this stuff, and maybe get feedback from the people making it?

    — Morgan Schweers, CyberFOX!

  25. Louis says:

    My only question is how would this differ from OPML, a four year old spec that’s already well known for storing a list of RSS feeds in newsreaders?


    I don’t really know enough about XML to compare the two myself 😉

  26. Yahoo, Microsoft, Apple. Ces trois soci&#233;t&#233;s ont un point commun. Celui d’avoir d&#233;velopp&#233; un module d’extension du format RSS 2.0. En mai, Yahoo! introduisait mediaRSS (mRSS), une s&#233;rie de balises d&#233;crivant les diff&#233;rents attributs d’un fichier multim&#233;dia. Plus r&#233;cemment, Microsoft…

  27. michael rose says:

    right now i am using SharpReader and ZoneAlarm firewall/antivirus and am concerned about a backdoor intrusions into my computer. although zonealarm has a very good stealth mode (verizon, my isp, was unable to see me until i turned off the stealth mode), and checks emails in outlook, it does not check RSS communications. is this a real problem and is it one that will be solved with RSS in ie 7?

  28. While making a RSS feed aggregator, I realized a lot of people read ATOM and RDF feeds also. It would be nice if there was a generic model to parse RSS, ATOM and RDF feeds the same way. Probably you guys can introduce RssReader and RssWriter like classes which behaves the same way as XmlReader/XmlWriter. Similarly AtomReader/AtomWriter classes?

    Also will RSS be included in next Outlook?

    I would be very happy if you take a look at my RSS Aggregator+Blog tool which works both Standalone and fully Office 2003 integrated. You can also blog to this CommunityServer using this!


    I will look forward to some comments from you guys regarding generic feed parser. I am sure as developers of RSS related libraries, we both go through the same "Aha!" factors everyday.

  29. Longhorn Team RSS Blog : Our welcome from (and to) the community: This blog entry on the Microsoft RSS team blog talks about adding lists to RSS. Here’s some of what it says: The other main thing that Dean…

  30. Charlie Wood says:

    Dave Winer wrote that he talked to you guys at Gnomedex and that you were going to revise the list extensions spec to address some of the concerns raised here. Have you done so? If not, when do you expect to, and what version of IE7 would reflect those changes?


  31. great i can make great use of this


Skip to main content