My token occasional "not actually related to my job" post, just typing to get my ideas down. I'm not employed as a programmer or PM, so expect questions, not policy statements!
I've put together a couple of RSS aggregator test apps in the past year or so, mainly to muck around with XML programming with .Net.
I must admit to being a bit confused about RSS/RDF. From a publisher's perspective, easy, just create the content and let The Masses suck it. Whatever your content, The Masses can consume it, as long as they have an aggregator of the correct type, and it does whatever the consumer is focused on. It's easy.
Most recently, I was toying with an RSS to NNTP server gateway application (I hate having to re-solve the Storage Problem, and like leveraging Outlook or other apps to do it for me) so that Outlook Express or Agent could consume it in their native tongue.
But where does RSS belong? Should OE consume feeds, or should Outlook? Does it really fit within one application? I'm not convinced I want all my feeds in Outlook. Should there be a completely separate feed engine? Should RSS (or Atom) be used for all applications, or should we be considering certain alternative derivative formats for types of content that don't necessarily match the Blog space? Does every app need to understand its own brand of RSS (in which case, why not just any old XML)? Does it make the user's life harder having a single format with multiple possible purposes and consumers?
Is this just an artificial distinction?
RssBandit and other standalone aggregators seem pretty good for surfing news, where you're mainly interested in the headline and are happy with link clicking to pull the content, but generally I enjoy reading Blog content in Outlook for some reason (perhaps it's more like a personal email to me that way?).
Subscribe to FlexWiki output, however, and you see a different class of feed - the really-not-for-the-user type of feed. Sure, it tells me that some Wiki was changed by some user - do I want an email? Would I rather have a pop-up notification and then ignore it (have optional persistent storage?). Likewise, if Sharepoint Alerts did RSS, I wouldn't necessarily want them in Outlook, I'd want a similar point-in-time notification. As a human, I despise RSS messages that are light on meaningful content, tell my “what's changed” application what's new and different.
This might “just go away” when and if aggregators get the WinFS mojo.
Ideally, (as an aggregator) I'd like to be able to move content directly into a WinFS version of Outlook (note: hypothetical, unannounced product here), just by creating Message items in the file system (and putting them in an Email folder hierarchy, or something). So rather than using the current COM extensibility API for Outlook to store stuff indirectly through Outlook, and other APIs for other applications, the messages could be created and managed directly in the file system, and tagged as Message items associated with Outlook, or as short-lifespan Notification items associated with my cute sidebar tile, or, well, whatever. The aggregator could be standalone, but effortlessly (well, with minimal effort) integrate with any given Messaging application I desired that used WinFS. I could have my cake and eat it too. Other WinFS-based applications could receive similar treatment.
If I ever get the WinHEC Longhorn build onto one of my real machines, I'll see what I can throw together. I like the idea, I don't know if it'll work in practice (I wonder if Longhorn Outlook Express uses WinFS in a way I can use?)