As I was researching my chapter on the Windows RSS platform for
RSS and Atom in Action I came up with a list of questions based on the IE7 previews. Scoble hooked me up with Walter VonKoch, who kindly answered them all.
1) The Feeds API documentation say that
<cf:id> is a unique ID. Within what scope is this ID unique?
Walter tells me that <cf:id>, which is mapped to FeedItem.ID in the Feeds API, is unique only within a feed.
2) Currently, when you view a feed from the local file-system in IE7, it appears as raw XML and not in the pretty feed view. In the final IE7, do you intend to make it be possible to view and subscribe to local file-system feeds?
Walter confimed that "http" and "https" are the only schemes
supported now, but "file" is desirable and may be supported in the
future.
3) Currently, it does not appear to be possible to create subscription to a local file-system feed using the Feeds API. This limits the Feeds API's usefulness as a general purpose feed parser. Do you intend to make it possible to parse local file-system feeds via the Feeds API?
See answer to #2
4) Unique item IDs are important to many applications and some aggregators use them to keep track of read/unread item state. RSS provides item IDs via the
<guid> element and Atom does it through
<id>, but neither of these values are available through the
IFeedItem interface. And the
IFeedItem.ID property returns the
<cf:id> value, which does not appear to be globally unique. So, do you intend to make the real item IDs available through API properties or will developers have to parse them out of the XML?
Walter made no promises here, but indicated that it's still possible that a GUID property might find it's way into the IFeedItem interface. I also recommended that the property that holds <cf:id> should be named listid or cfid instead of ID.
6) The Common Feed extensions (
<cf:id>,
<cf:read> and etc.) exist within the same namespace as the Simple List Extensions, but they are not part of the Simple List Extensions specification. Do you intend to add the CF extensions to the Simple List Extensions specification or create a whole new spec?
The Common Feed extensions will not be added to the Simple List Extensions spec. They'll be moved into their own namespace. Walter didn't say if a new spec would be created for them, but I have to assume that one would.
8) Can you comment on which parts of the Windows RSS platform are likely to see the most change before the platform's initial release in IE7? Are there any significant new features that you intend to add or any that you intend to remove?
Walter said that the Beta 2 is supposed to be feature complete, but changes due to feedback are still possible.
7) How likely is it that the namespace URI for the Common Feed extensions will change?
See answer to #6
5) There appear to be some bugs in the handing of item-level author elements, so it's not clear what your intentions are. If both
<dc:creator> and RSS
<author> appear in an RSS item, do you intend to map them both to the same
<atom:author> element?
If both are present they'll each be mapped to a <atom:author> element.
9) I've had a hard time finding IE7 schedule information. What is the publicly announced schedule for IE7 beta and final releases?
For IE7 these are
Beta 2 - H1CY06
RTW - H2CY06
And for Vista are:
RTM is Nov 2006 for Enterprise, Jan 2007 for Consumer.
Beta2 about the same time as IE7
10) I've heard that the Feeds API will not download enclosures that are EXEs and DLLs (and other naughty bits), but I have not tested this. So, a) is this true and b) is it possible to configure the system to allow downloads of EXE and DLL files from certain select Web sites?
Walter says this is controlled via the Attachment Execute Service (AES) that was introduced with Windows XP SP2. The enclosure downloader operates in the InternetZone and therefore by default, EXEs won't be downloaded. See KBID-883260 for more info. And that's it. Thanks again to Microsoft's Walter VonKoch for taking the time to my questions.
Posted by James Snell on April 11, 2006 at 03:20 PM EDT #
Posted by Bob Aman on April 11, 2006 at 11:58 PM EDT #
James: I think they're seriously considering mapping guid/id and they're just playing cautious with commitments, nothing wrong with that.
Bob: you can get the XML for a feed or for an individual item and, although it is not the original XML of the feed (it's a normalized RSS/Atom format), any namespaced extensions are preserved.
Posted by Dave Johnson on April 12, 2006 at 12:35 AM EDT #
I'm afraid that the GUID they will add to the IFeedItem interface is not the globally unique ID you might find in an Atom feed, but instead a GUID generated "on the fly" by the RSS Platform when a feed entry/item is deserialized.
So there will be information loss and seemingly no way to get it out. What they could do, is add a general GetNode() method to an IFeedItem implementation that accepts an XPath query as a parameter and returns a System.Xml.XmlNode which then can be manipulated.
Or, since the IFeedItem is infact an interface, it could be possible to create a custom implementation (e.g. AtomFeedItem) that can override the 'ID' property to return the ID found in the Atom feed.
Posted by Asbjørn Ulsberg on April 12, 2006 at 07:01 AM EDT #