Udostępnij za pośrednictwem

Our welcome from (and to) the community

  • Artykuł

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

Comments

  • Anonymous
    June 25, 2005
    The comment has been removed
  • Anonymous
    June 25, 2005
    The change looks good. I definitely concur with Phil that you're going to run into issues with @namespace="&quot;. 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?

    Strawman:
    &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&quot; and the value of @order is "desc" or "asc".
  • Anonymous
    June 25, 2005
    This looks like a good change to me.
  • Anonymous
    June 25, 2005
    Why not simply alow the cf:sort and cf:group elements to be placed at the feed level?
  • Anonymous
    June 25, 2005
    I like the change and the suggestions made above as well.
  • Anonymous
    June 25, 2005
    Sean: Definitely a positive change. Although honestly, I'm still partial toward something like:

    [item]
    [title cf:data-type="text"]my title[/title]
    [dc:date cf:data-type="date"]2005-03-01[/dc:date]
    [/item]

    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.
  • Anonymous
    June 25, 2005
    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 -
    http://www.w3.org/TR/rdf-primer/
  • Anonymous
    June 25, 2005
    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
  • Anonymous
    June 26, 2005
    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 :

    http://groups.yahoo.com/group/syndication/message/586
  • Anonymous
    June 26, 2005
    I wrote a little note to you guys about what I think you can improve with your demos.
    http://studio.partlysane.com/2005/06/26/note-to-microsoft-and-the-rss-team/

    Love the idea though. Keep up the good work and keep trying to get those other Microsoft teams to jump onboard the RSS train.
  • Anonymous
    June 26, 2005
    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:listinfo>
    <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
    </cf:column>
    </cf:listinfo>

    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.
  • Anonymous
    June 26, 2005
    The comment has been removed
  • Anonymous
    June 27, 2005
    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!
  • Anonymous
    June 27, 2005
    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
  • Anonymous
    June 27, 2005
    The comment has been removed
  • Anonymous
    June 27, 2005
    The comment has been removed
  • Anonymous
    June 27, 2005
    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:

    <item>
    <title>this is required</title>
    <netflix:movieName>Step Into Liquid</netflix:movieName>
    <netflix:movieRating>5</netflix:movieName>
    </item>
    <item>
    <title>this is required</title>
    <netflix:movieName>Chicago</netflix:movieName>
    <netflix:movieRating>3</netflix:movieName>
    </item>

    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:

    <item>
    <title>this is required</title>
    <cf:row>
    <cf:column>
    <cf:name>MovieName</cf:name>
    <cf:value>Step Into Liquid</cf:value>
    </cf:column>
    <cf:column>
    <cf:name>MovieRatings</cf:name>
    <cf:value>5</cf:value>
    </cf:column>
    </cf:row>
    </item>
    <item>
    ...
    </item>

    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,

    <cf:column>
    <cf:name>MovieAvailibility</cf:name>
    <cf:value>true</cf:value>
    <cf:value-live>http://...</cf:value-live>
    </cf:column>

    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:

    <channel>
    <cf:columnDef>
    <cf:name>MovieName</cf:name>
    <cf:sortable>true</cf:sortable>
    <cf:groupable>false</cf:groupable>
    </cf:columnDef>
    ...
    </channel>

    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.
  • Anonymous
    June 27, 2005
    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?
  • Anonymous
    June 27, 2005
    The comment has been removed
  • Anonymous
    June 28, 2005
    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,...
  • Anonymous
    June 28, 2005
    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.
  • Anonymous
    June 29, 2005
    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...
  • Anonymous
    June 29, 2005
    Hi,

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

    http://www.ldodds.com/blog/archives/000220.html
  • Anonymous
    June 30, 2005
    The comment has been removed
  • Anonymous
    July 02, 2005
    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?

    http://www.opml.org/spec

    I don't really know enough about XML to compare the two myself ;)
  • Anonymous
    July 04, 2005
    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...
  • Anonymous
    July 10, 2005
    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?
  • Anonymous
    July 11, 2005
    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!

    http://rssfeederdotnet.sourceforge.net

    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.
  • Anonymous
    July 13, 2005
    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...
  • Anonymous
    July 31, 2005
    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?

    Thanks.
  • Anonymous
    October 15, 2005
    public-safety
  • Anonymous
    October 15, 2005
    public-safety
  • Anonymous
    November 15, 2005

    http://pd2.funnyhost.com
    <a href="http://pd3.funnyhost.com">pd3</a>
    [url=http://pd4.funnyhost.com]pd4[/url]
  • Anonymous
    February 06, 2006
    great i can make great use of this
    cheers
  • Anonymous
    February 27, 2006
    juzju