RE: Atom Rank Extensions
David, Looks like I picked a good time to catch up on Atom-syntax mail. Actually - can cf:list be used together with cf:[EMAIL PROTECTED]'true'?, Yes, it can. See the example in the explanatory doc we posted a while back. http://blogs.msdn.com/rssteam/articles/SimpleListExtensionsExplained.aspx That example feed is online here: http://sean.members.winisp.net/lists/bookexample.xml -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Powell Sent: Wednesday, May 03, 2006 12:31 PM To: James Holderness Cc: atom-syntax Subject: Re: Atom Rank Extensions Tuesday, May 2, 2006, 10:06:51 PM, James Holderness wrote: Just looking at that example, it seems to me that an aggregator that implements Microsoft's simple list extensions would get a full-featured representation of that feed without having to know anything at all about feed rank and feed history. So why bother with them? I made a suggestion for avoiding implicit ordering in SLE on the FEED-TECH list[1]. Basically to allow the cf:treatAs to use the @element and @data-type attributes that are used in cf:sort and cf:group elements, so that entries could include a datestamp, or index, which could be used for the ordering of the list rather than the natural ordering. [1] http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0603dL=feed-techT=0F=S=P=312 Actually - can cf:list be used together with cf:[EMAIL PROTECTED]'true'?, I think I'll ask... -- Dave
RE: Does xml:base apply to type=html content?
However, exempting [EMAIL PROTECTED]'html'` content from xml:base processing won't help. Agreed and an excellent point. I guess that the end-result of this is that regardless of how one wants to interpret any of the relevant specs on this issue, a client should assume that xml:base applies to URI references in @type=html content. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis Sent: Thursday, March 30, 2006 6:31 PM To: Atom Syntax Subject: Re: Does xml:base apply to type=html content? * Sean Lyndersay [EMAIL PROTECTED] [2006-03-31 04:00]: This is unfortunate, because HTML itself only allows base elements in the header (one per page). So if anyone wants to build a client that displays more than one item at a time using a standard HTML renderer (and most client render HTML using someone else's renderer, not their own), they have to go groveling in HTML to do URL fixup (or use iframes). That's exactly the problem currently facing Liferea. However, exempting [EMAIL PROTECTED]'html'` content from xml:base processing won't help. If the items can come from multiple feeds, such as is supported by Liferea, then mixing items from an Atom feed that uses xml:base and other feeds automatically runs into the same issue. In that scenario, either the tag soup from the other feeds must be fixed up so the view can be rendered as XHTML (which supports xml:base in content), or URL fixup needs to be done on the content from the Atom feed so it can be passed to a tag soup renderer. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
RE: Does xml:base apply to type=html content?
I haven't looked in detail at how IE does on the xml:base comformance tests, since the current beta has no support for xml:base. In light of that fact, I'm glad we failed outright instead of halfway; halfway would have been weird :). We're actually implementing xml:base support right now (and in the process, fixing the relative URL issue that Sam Ruby pointed out in our normalization format), so we'll be broken on those conformance tests for while. The fix won't make it out in the next public release, but it should make the one after that. I'll let you know how we do on those tests when the code is done. Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Holderness Sent: Thursday, March 30, 2006 9:24 PM To: Atom Syntax Subject: Re: Does xml:base apply to type=html content? Sean Lyndersay wrote: In my own case (IE7) case, this isn't that big a deal because we have to grovel in HTML for many other reasons, but I suspect it'd be pain for other clients. Looking at the results of the Atom XmlBaseConformanceTests [1] mosts of the clients tested seemed capable of handling relative references inside HTML to some extent. Even the ones that don't necessarily pass all the tests at least get enough right to suggest that they're on the right track. IE7 is actually one of the few clients that I would consider to have failed outright. Is the latest beta any better at handling xml:base or do these problems still exist? Regards James [1] http://www.intertwingly.net/wiki/pie/XmlBaseConformanceTests
RE: Does xml:base apply to type=html content?
This is unfortunate, because HTML itself only allows base elements in the header (one per page). So if anyone wants to build a client that displays more than one item at a time using a standard HTML renderer (and most client render HTML using someone else's renderer, not their own), they have to go groveling in HTML to do URL fixup (or use iframes). In my own case (IE7) case, this isn't that big a deal because we have to grovel in HTML for many other reasons, but I suspect it'd be pain for other clients. My own reading goes like this: Since xml:base is an XML concept, it should apply only to relative references in XML content (including XHTML). From the XML perspective, the HTML content is just a string, so the xml:base should not apply. Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray Sent: Thursday, March 23, 2006 10:49 AM To: David Powell Cc: Atom Syntax Subject: Re: Does xml:base apply to type=html content? On Mar 23, 2006, at 10:03 AM, David Powell wrote: xml:base applies to type=xhtml content, but I'm not sure whether it is supposed to apply to escaped type=html content? I reckon that it does. RFC4287, section 2: Any element defined by this specification MAY have an xml:base attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an Atom Document, it serves the function described in section 5.1.1 of [RFC3986], establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute. Seems pretty clear to me. Yes, the base URI of that HTML is now whatever xml:base said it was -Tim
RE: IE7 Feed Rendering Issue
Ive been meaning to respond to this in the original thread (and to David Petersons offline questions publicly), but got caught up in some other things. There are a few principles we used to decide how to approach this problem (and its not a straightforward issue with an easy decision matrix): First, while the feed itself is data (as David points out ), the entries are the content from the publisher. The publisher has complete control over how each item in the feed looks (using (X)HTML). Entries can, of course, be re-mixed and shown in different contexts, losing their original feed context. It is worth noting that no other aggregator maintains the publishers look and feel on a feed. RSS Bandit and some others allow the user to control how a feed looks, and it requires custom, app-specific XSLs. If Safari has a way to turn off its feed view, I havent found it yet. To build on this idea, there is real value on a consistent view of feeds for the user, helping the user understand what they are looking at, and the context in which they can use the data. In fact, thats part of the promise of RSS consistency. For example, because the feed view is part of the client, instructions explaining what a feed is, and why subscribing is a useful and interesting thing to do are presented in the users system language, regardless of the language of the feed. If the user chooses, they can turn off the IE feed view completely (starting from the next beta update). Finally, we think that feeds+stylesheets exist as a stopgap measure to help users avoid the nasty XML view in browsers that dont support feeds (yes, this is a generalization, and some people are building web sites that are built in a more complicated way, but in the vast majority of cases, its true). Now that the browsers support viewing feeds natively (this will be all major browsers, with the release of Firefox 2.0), this stop gap should be retired, or continue to exist only for older browsers. There is a reasonable argument that this is a change in browser behaviour, and theres mention in another email that this is counter to the IE7 CSS promise of compatibility with sites. The reality is that browsers have a nightmare process of dealing with millions of websites that have a near infinite set of permutations of how they use HTML. This is a side effect of the somewhat haphazard evolution of HTML in the 90s. I think it would be a complete mistake to repeat that here. The feed is nowhere near as large as the HTML community, and the opportunity exists to correct behaviour and do the right thing. Yes, its a change in browser behaviour, but that should not be the only argument. Since we are still at the cusp of the explosion of RSS/Atom into the mainstream, we should be deciding what is the right thing. I argue that the right thing for a publisher is to serve HTML when they want control over the look and feel of the entire set of content, and to serve RSS/Atom when they want their data consumed as a feed (which has always meant surrendering the look-and-feel to the particular client the user chooses). To address another implied point we are not doing this out of some evil intent to screw the publisher or other clients. We have gone into this with the explicit intent of not only providing a decent feed reading experience in IE, but also to make sure that the entire community of aggregator and services is catered to we have built and published extensive support for other aggregators and services to hook into the feed discovery experience and to synchronize with the Common Feed List that ships with IE. When a user subscribes to a feed using IE, hes not limited to using IE to read that feed. Any aggregator can build support for the publicly documented APIs to read and write to the Common Feed List, and any service can build support for synchronizing that feed with their service (and in both cases, several are doing so right now). I hope this helps make the reasoning behind IEs behaviour with feeds and stylesheets a little less murky. Thanks, Sean From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Nesting Sent: Thursday, March 09, 2006 7:30 AM To: [EMAIL PROTECTED] Cc: atom-syntax@imc.org Subject: Re: IE7 Feed Rendering Issue On 3/9/06, Klaus Johannes Rusch [EMAIL PROTECTED] wrote: Unless the context is stored with the feed, the user experience will be different when a user follows a link from another page (rendered as Web page) and later loads the same link again from the bookmarks (rendered as an XML feed). If this is just an issue with the example rules, that's solvable by adapting the rules to match expectations. Maybe browsers would be willing to store some sort of context along with the bookmark. But really the underlying point is that browsers and/or feed readers can choose to render the feed however they want. The Atom syntax does not require xml-stylesheet support nor does any part
RE: IE7 Feed Rendering Issue
This is off-topic, but Ill answer quickly. If someone wants to go into this in more detail, contact me offlist. Given that weve re-done the look-and-feel of the built-in stylesheet about 3 times since Beta 1 (its changed again in the next beta release), it obvious that people have lots of opinions about what looks right for them. So, in some future release (not IE7) we will definitely add the ability for the user to customize the look-and-feel of feeds in IE. As for the API, the documentation for the RSS API is here: http://msdn.microsoft.com/library/en-us/feedsapi/rss/overviews/msfeeds_ovw.asp Theres an sample app here: http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx Thanks, Sean From: M. David Peterson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 12:28 PM To: James Yenne Cc: A. Pagaltzis; atom-syntax@imc.org; Sean Lyndersay Subject: Re: IE7 Feed Rendering Issue * Why can't I publish my own stylesheet and use these Microsoft elements for collation, background, etc.This Microsoft stylesheet should be replaceable. * I would say this is a quite valid question. Is this capability planned and has simply not been implmented at this stage? I realize the look and feel of the browser itself will be handled via the standard Windows Themes interface when this, in fact, is changed by the user. Will this stretegy be the primary strategy moving forward? Of course, the ultimate question James has posed is most particular to the web feed itself. It's simple enough to go in and play with the DOM via the various GreaseMonkey clones for IE, so obviously where theres a will, the way has already been paved. But this is obviously not an IE strategy, and instead a vendor hack. Of course, it seems to me that the piece that is missing has nothing to do with all of this... the piece that is missing is maybe our own realization that there is an RSS API that, from what I understand (lloks like a new item will be added to my study list for the week :), allows the ability to develop a completely different rendering engine all together that ties into the RSS backbone such that no matter what interface is use, IE-based, XAML-based, WinForms-based, etc each can stay consistent with the same set of data. Thats actually pretty cool when you think about it. Would be cooler if it had a more snazzy name to the backend system... something like AtomicRSS but then again, theres nothing stopping me or anyone else from building just such an interface that could act as the Atom-enhanced version of the of the RSS backbone... I sure do love the idea of extensions, I tell ya ;) :D On 3/9/06, James Yenne [EMAIL PROTECTED] wrote: * Sean Lyndersay [EMAIL PROTECTED] [2006-03-09 17:05]: To build on this idea, there is real value on a consistent view of feeds for the user, helping the user understand what they are looking at, and the context in which they can use the data. In fact, that's part of the promise of RSS - consistency. +1 While I agree in principle, my concern is that as Microsoft moves forward with this reasonable tact for IE and on behalf of the web feed community, Mozilla, Safari and others will have their own solution which is different and also consistent.The published SSE extensions are a good step in making this consistency stick, but will these others use SSE or yet another solution.Why can't I publish my own stylesheet and use these Microsoft elements for collation, background, etc.This Microsoft stylesheet should be replaceable. Finally, we think thatfeeds+stylesheets exist as a stopgap measure to help users avoid the nasty XML view in browsers that don't support feeds (yes, this is a generalization, and some people are building web sites that are built in a more complicated way, but in the vast majority of cases, it's true). +1 I argue that the right thing for a publisher is to serve HTML when they want control over the look and feel of the entire set of content, and to serve RSS/Atom when they want their data consumed as a feed (which has always meant surrendering the look-and-feel to the particular client the user chooses). +1 Sure, serving XHTML is just a one off for my app, but part of my goal is to clarify this behavioral standard for the browser / feed reader / aggregator community. The publisher is thus henceforth locked into the IE browser's look and feel for the subscription presentation page, which works fine of course.This is a browsers becoming a reader and an aggregator, and it's tricky. -James -- M:D/ M. David Peterson http://www.xsltblog.com/
RE: IE7 Atom Handling (was RE: Link rel attribute stylesheet)
This is fantastic, David. Many thanks. We're going over your feed in detail and I'll respond with bug information as soon as possible. Thanks, Sean -Original Message- From: David Powell [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 01, 2006 11:33 AM To: Sean Lyndersay Cc: atom-syntax@imc.org Subject: Re: IE7 Atom Handling (was RE: Link rel attribute stylesheet) Hi Sean, I've been testing IE7 beta 2's support for Atom, with the following test feed: http://djpowell.net/atom-test/hardfeed/feed/hard-feed.atom Also here for easier viewing in IE7 http://djpowell.net/atom-test/hardfeed/feed/hard-feed.xml Here are the problems that I have found: 01. Person Extensions In Atom, extension elements can appear in feeds, entries, and person constructs. So atom:author and atom:contributor should preserve any extension elements. Currently, the transform only preserves atom:uri, atom:name, and atom:email. It should preserve all extensions too. 02. Timezones atom:updated is converted to RSS's RFC822 pubDate element, but the timezone information is lost. Eg: a date such as 2006-01-01T05:00:00+02:00 is converted to Sun, 01 Jan 2006 05:00:00 GMT, which is incorrect. 03. atom:published While atom:updated is converted to pubDate, atom:published is kept as atom:published; except, the date format is converted to RFC822 format. I think that the date format should be kept as-is in ISO8601-style format. 04. Alternate links for non-HTML types The entry called Binary Entry contains a link of the form: atom:link href=../files/bin.png length=684 type=image/png / This link isn't treated as the link for the entry, presumably because it has a type other than HTML. If no HTML link can be found for the alternate link, perhaps it would be worth just choosing any other alternate link instead. 05. HTML titles HTML in feed and entry titles is interpreted properly, but flattened to text. This is presumably deliberate but it does mean that there is some data loss. Perhaps the original atom namespaced element should be preserved as well in these cases? 06. atom:generator atom:generator is converted to RSS's generator. The uri attribute is included as an unnamespaced uri, but the version attribute is dropped. Perhaps both should be preserved, and it might be better to put the attributes into a namespace? 07. XHTML namespace prefix More of a rendering problem, but I've included it here because it is significant: xhtml content currently only works if the xhtml is in the default namespace. If a namespace prefix is used, it fails to be interpretted correctly. See the entry entitled: Entry with full iana [EMAIL PROTECTED] values; the link should appear as an HTML link, but doesn't. 08. IANA URIs for link relations A bit of a quirky one, but in Atom the rel values are actually URIs relative to http://www.iana.org/assignments/relation/, so rel=alternate and rel=http://www.iana.org/assignments/relation/alternate; should be treated the same. The same goes for enclosures. See the entry: Entry with full iana [EMAIL PROTECTED] values, which should show an enclosure and a valid entry link. 09. Category label atom:category is converted to RSS's category element. This causes the label attribute to be lost. It perhaps should be preserved as a namespaced attribute. Also, if it is available it might be better to use the label rather than the term as the RSS2 category name, because term might not be very human readable, that is the purpose of label. See Content Source Entry, which causes the WordNet URI to be displayed in the category filter box. 10. xml:base everywhere Some handling of xml:base is done if it appears on atom:feed or atom:entry, but it can appear anywhere. Eg, xml:base on the atom:link element should affect that link. There are a number of examples of xml:base being handled wrongly in the example, eg the broken feed logo. 11. xml:base / xml:lang namespace I notice that lang and base attributes appear on the transformed feed, but don't have the xml: namespace prefix? Is this a bug caused by the weirdness of the implicit xml: namespace? 12. Subscription name An IE7 bug, but I'll mention it here: If the feed title contains a line-break, the Subscribe to feed-dialog doesn't work because the line-break get's embedded as a hollow-square in the text box and causes an error. Try subscribing to the test feed, it works if you remove the hollow-box from the subscription name. 13. xml:base and xml:lang inheritance from atom:feed to entries xml:base and xml:lang at feed level should apply to all elements nested within the feed document. However the atom:feed element and its metadata can obviously change over time. This creates a problem: What if the atom:feed element contains an xml:base element, and it changes. The feed document as polled can be assumed to be consistent, but it would be wrong to retroactively apply this new base to old entries. In order to avoid these problems each
RE: Fwd: [rss-public] Microsoft Feeds API Enclosure Test
The normalized XML that you're seeing in View Source is also accessible from the feed APIs, so the XML we generate is a format we expect to support in perpetuity. It's designed to be a relatively simple format that application developers can rely on in the same way that they rely on APIs in the object model, so we map all common elements from other formats into RSS 2.0 (the basis for our native format). Why RSS 2.0? Because it's the format used by the majority of feeds on the web. Since this is an internal format between the platform and its clients, it theoretically doesn't matter what we chose as long as there's no data loss (and as long as we document it -- which we're in the process of doing). In the Atom case, in particular, we occasionally need to bring Atom elements through as RSS 2.0 extensions. Any case of data-loss is a bug that we'll address (that's the point of a Beta :). If you have cases of sites where there is data-loss, you can either send it me, send it to [EMAIL PROTECTED] or post to the feedback wiki where we're tracking feeds that we're not handling correctly [1]. I'm in the process of publishing the documentation for how the Windows RSS Platform handles each feed format on our blog [2]. If someone does have a particularly complex Atom feed, we'd love to use it for our own testing to make sure we're handling all of the Atom-specific data correctly, so just send me a link. As a general statement, if you have question about what IE7/Windows is or is not doing with feeds, just drop me a line. Thanks, Sean [1] http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerFeedIssues [2] http://blogs.msdn.com/rssteam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Powell Sent: Thursday, February 23, 2006 7:29 AM To: A. Pagaltzis Cc: Atom Syntax Subject: Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test Thursday, February 23, 2006, 6:37:50 AM, you wrote: Does someone who has access to an MSFT system care to take a look at this? I have been playing with IE7, and it is interesting to see what happens when you click on a feed and view source. If the feed hasn't been subscribed to, you just see the feed source as you would expect. If you have subscribed to the feed however, you see Windows's internal representation of the feed, which is normalised to a sort of RSS2++. I assume that this is what is exposed when you use the APIs to access the XML. (Hmm - giving access to the XML in this way is a brave move, XML has a huge surface area for an API, practically any change to the XML produced by Windows could break client applications, and I didn't find any documentation for the normalised RSS2++ ). What is interesting is that Atom is handled (reasonably well), by converting the Atom to RSS2. The logic seems to replace atom elements with there RSS2 equivalents and the loss in fidelity is not too great (eg atom:updated - pubDate), and to leave the Atom as-is for awkward (eg: [EMAIL PROTECTED]/xml) There is definitely some loss in fidelity though. It would be nice to run an extreme Atom feed through the process to see what gets lost. xml:base appears to get corrupted, and unless the API provides access to the baseURI of each entry there is a risk of data loss (as the xml:base at feed level may change between polls it therefore needs to be preserved with each entry.) Does anyone have a bad-ass atom feed with IRIs, binary content, atom:source, xml:base, xml:lang, extensions etc for testing? -- Dave
RE: [rss-public] Microsoft Feeds API Enclosure Test
To answer the original question here, IE7 (and the Windows RSS Platform)
doesn't support multiple enclosures in the current release.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis
Sent: Wednesday, February 22, 2006 10:38 PM
To: Atom Syntax
Subject: Fwd: [rss-public] Microsoft Feeds API Enclosure Test
Does someone who has access to an MSFT system care to take a look at this?
From: James M Snell [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [rss-public] Microsoft Feeds API Enclosure Test
Date: Wed, 22 Feb 2006 21:28:19 -0800
Message-ID: [EMAIL PROTECTED]
List-Id: rss-public.yahoogroups.com
Hmm.. interestingly, this API also looks as if it would stuff multiple
enclosures in Atom also... in which case, I'd argue that the API is
simply broken.
rcade wrote:
Power Line has a podcast feed that includes multiple enclosures, as
someone pointed out earlier on this list:
http://www.powerlineblog.com/podcasts.xml
A cached copy of this feed is here:
http://www.rssboard.org/files/example-multiple-enclosures.xml
This feed contains one item with one enclosure, a second with three
enclosures, and a third with three enclosures (in that order).
After subscribing to this feed in MSIE 7 and choosing automatic
downloads of enclosures, I wrote a VB.NET console application that
displays the URL of each enclosure in the feed:
Sub Main()
Dim fm : fm = CreateObject(Microsoft.FeedsManager)
Dim fmroot = fm.RootFolder
Dim plfeed = fmroot.getFeed(Power Line)
Dim i
For i = 0 To plfeed.Items.Count - 1
Dim item = plfeed.getItem(i)
Console.WriteLine(Title: + item.Title)
Dim plenclosure = item.Enclosure()
Console.WriteLine(Enclosure: + plenclosure.Url)
Console.WriteLine()
Console.Write(item.xml(1))
Console.WriteLine()
Next
End Sub
Here's the output of the application (with item elements other than
enclosure removed from the XML):
-- BEGIN OUTPUT --
Title: Listen to Col. Stephenson and Judge for Yourself
Enclosure: http://powerlineblog.com/podcasts/NA218Stephenson.mp3
itemenclosure
url=http://powerlineblog.com/podcasts/NA218Stephenson.mp3;
length=21455322 type=audio/mpeg
xmlns:cf=http://www.microsoft.com/schemas/rss/core/2005;
cf:path=C:\Documents and Settings\Rogers\Local Settings\Temporary
Internet
Files\Enclosure\{0C1E2407-FAE4-447F-9054-FB1C7CFE6A86}\Listen
to Col. Stephenson and Judge for Yourself.mp3
cf:downloadstatus=Downloaded//item
---
Title: New Podcast: Yesterday's Northern Alliance Radio Network
Enclosure: http://powerlineblog.com/podcasts/Feb111stHourPt1.mp3
itemenclosure
url=http://powerlineblog.com/podcasts/Feb111stHourPt1.mp3;
length=19949804 type=audio/mpeg
xmlns:cf=http://www.microsoft.com/schemas/rss/core/2005;
cf:path=C:\Documents and Settings\Rogers\Local Settings\Temporary
Internet Files\Enclosure\{0C1E2407-FAE4-447F-9054-FB1C7CFE6A86}\New
Podcast Yesterday's Northern Alliance Radio Network.mp3
cf:downloadstatus=Downloaded/enclosure
url=http://powerlineblog.com/podcasts/Feb111stHourPt2.mp3;
length=8550404 type=audio/mpeg/enclosure
url=http://powerlineblog.com/podcasts/Feb112ndHour.mp3;
length=15032924 type=audio/mpeg//item
---
Title: Now Podcasting: The Northern Alliance Radio Network!
Enclosure: http://powerlineblog.com/podcasts/January21,1stHour.mp3
itemenclosure
url=http://powerlineblog.com/podcasts/January21,1stHour.mp3;
length=39923577 type=audio/mpeg
xmlns:cf=http://www.microsoft.com/schemas/rss/core/2005;
cf:path=C:\Documents and Settings\Rogers\Local Settings\Temporary
Internet Files\Enclosure\{0C1E2407-FAE4-447F-9054-FB1C7CFE6A86}\Now
Podcasting The Northern Alliance Radio Network!.mp3
cf:downloadstatus=Downloaded/enclosure
url=http://powerlineblog.com/podcasts/January212ndHourPt1.mp3;
length=14954800 type=audio/mpeg/enclosure
url=http://powerlineblog.com/podcasts/January212ndHourPt2.mp3;
length=12517975 type=audio/mpeg//item
---
-- END OUTPUT --
The Feeds API refers to an item enclosure singularly. The only method
I found reads a enclosure from an item. When multiple enclosures are
present, item.Enclosure() retrieves the first.
An item's xml(1) method produces its contents as XML, with the
numeric
1 argument indicating that Microsoft's common format feed elements,
and Simple List Extensions should be included in the output.
The XML output includes the multiple enclosures, in which the
cf:downloadstatus element only is present for the first enclosure in
each item.
Checking the Temporary Internet Files folder where enclosures are
being stored, only the first enclosure in each of the three items is
present.
As the Feeds API is presently implemented, publishers of RSS
RE: Fwd: [rss-public] Microsoft Feeds API Enclosure Test
Thanks James, There's a general comment about normalization that I should address. First, normalization is something we have to do -- every aggregator on the planet has a native format that they work with, and they convert to that format before doing anything else. In our case, since we're developing a platform as well, we make that normalized format available to any user of the platform. We also provide a object model over the normalized feed. The primary reason for providing XML is that some developers find it easier to build applications using XML+XSL/XPath, rather than using an object model. The other major reason is to enable access to any elements that we don't natively support (i.e. most extensions) in the object model. To make this easier, we provide access to normalized XML version of the entire feed, or a fragment that represents a single item. Giving the original format to the developer is of questionable value since that makes the developer have to do all the work of learning 4 different feed formats just to get the data they need. For this reason, we kept the normalized format as close the most commonly used format (RSS 2.0) as possible, with extensions where necessary to keep the spirit of the Atom 1.0 format intact. Obviously, we have some bugs still, as you've pointed out, which we'll address for the next Beta. I'm sure that many people -- on this list in particular -- think that the right thing to do is to normalize to Atom 1.0, instead. Yep, that's certainly one way to think about it. But then I'd be having this same discussion with Dave and with folks on rss-public. :) In short, I'd rather avoid the issue altogether and provide some value to the developers who are using the platform -- which means preventing them from having to learn several different formats to get common data, while allowing them to get access to extensions. Addressing your post's issues in order: #1. We make no active effort to re-order the items in the feed. By default, they should end up being ordered by the date elements in the feed. As you noted, neither Atom nor RSS 2.0/1.0 require that order be respected. #2. Stripping out extensions. This is a bug we'll address. #3. Invalid Atom. This is a bug we'll address. #4. We'll look into addressing this with a namespace. Thanks for the detailed post and comments. If you have any other questions, just let me know. Sean -Original Message- From: James M Snell [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 2:39 PM To: Sean Lyndersay Cc: Atom Syntax Subject: Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test Thanks for the heads up on this. Check my blog[1] for a few comments [1] http://www.snellspace.com/wp/?p=268 - James Sean Lyndersay wrote: The normalized XML that you're seeing in View Source is also accessible from the feed APIs, so the XML we generate is a format we expect to support in perpetuity. It's designed to be a relatively simple format that application developers can rely on in the same way that they rely on APIs in the object model, so we map all common elements from other formats into RSS 2.0 (the basis for our native format). Why RSS 2.0? Because it's the format used by the majority of feeds on the web. Since this is an internal format between the platform and its clients, it theoretically doesn't matter what we chose as long as there's no data loss (and as long as we document it -- which we're in the process of doing). In the Atom case, in particular, we occasionally need to bring Atom elements through as RSS 2.0 extensions. Any case of data-loss is a bug that we'll address (that's the point of a Beta :). If you have cases of sites where there is data-loss, you can either send it me, send it to [EMAIL PROTECTED] or post to the feedback wiki where we're tracking feeds that we're not handling correctly [1]. I'm in the process of publishing the documentation for how the Windows RSS Platform handles each feed format on our blog [2]. If someone does have a particularly complex Atom feed, we'd love to use it for our own testing to make sure we're handling all of the Atom-specific data correctly, so just send me a link. As a general statement, if you have question about what IE7/Windows is or is not doing with feeds, just drop me a line. Thanks, Sean [1] http://channel9.msdn.com/wiki/default.aspx/Channel9.InternetExplorerFe edIssues [2] http://blogs.msdn.com/rssteam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Powell Sent: Thursday, February 23, 2006 7:29 AM To: A. Pagaltzis Cc: Atom Syntax Subject: Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test Thursday, February 23, 2006, 6:37:50 AM, you wrote: Does someone who has access to an MSFT system care to take a look at this? I have been playing with IE7, and it is interesting to see what
RE: [rss-public] Microsoft Feeds API Enclosure Test
Yes, I agree that failure to model Atom 1.0 feeds accurately is a bug, though as Paul Hoffman pointed out off-list, there is at least one scenario where we will fail to do this (at least for this release), which is signed entries. So, a more accurate way to state it, would be that, given the choice to normalize to RSS 2.0, we will do everything we can to ensure that the information publisher's puts in the feed is available to developers using the API. For what it's worth, there will be updates to this API over time, so it is possible that we will have an API that makes the content available in Atom format, as well (or in the native format, though that's harder because it requires that we persist the original XML). This feedback is all extremely useful in helping us figure out what the right thing to do is. Thanks, Sean -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 4:02 PM To: Sean Lyndersay Cc: James M Snell; Atom Syntax Subject: Re: [rss-public] Microsoft Feeds API Enclosure Test On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote: I'm sure that many people -- on this list in particular -- think that the right thing to do is to normalize to Atom 1.0, instead. Yep, that's certainly one way to think about it. But then I'd be having this same discussion with Dave and with folks on rss- public. :) In short, I'd rather avoid the issue altogether and provide some value to the developers who are using the platform -- which means preventing them from having to learn several different formats to get common data, while allowing them to get access to extensions. Given that Atom 1.0, in practice, is a clean superset of RSS 2.0 (there are things in RSS 2.0 that aren't in Atom, but they are typically not used; see http://www.tbray.org/atom/RSS-and-Atom), the only one that's been through a formal standardization process, and the only that's guaranteed not to change (see IETF rules) this feels a little weird. But it's your API. I will say, though, that there are already a lot of Atom 1.0 feeds and there are going to be more, so it does seem like a basic requirement that your interface be able to model Atom 1.0 accurately without data loss. I assume you agree that a failure to do this would be a bug. -Tim
RE: Fwd: [rss-public] Microsoft Feeds API Enclosure Test
As an format that is not intended for publishing on the web, but which is really a contract between the platform and the clients of the platform, the native format we use is not really required to be pure RSS 2.0. As I said, we use RSS 2.0 as the basis for the native format to leverage developers understanding of that format. I don't think that the addition of a single attribute to an element quite invalidates the entire premise, but if it really upsets everyone, we can put it in a namespace. Obviously, the further off the beaten path you get from typical feeds, the less like a pure RSS 2.0 feed it will look. Especially in the case of Atom 1.0, we detect various cases that aren't supported by RSS 2.0, and model them as extensions. Binary content is an example where we'll include the entire atom element as an RSS 2.0 extension in the feed. Since RFC 822 doesn't support sub-second times, we'll truncate those in the XML we return, but the sub-second times is available via the object model, if an application needs it. Right now, we don't support multiple enclosures, so representing it in the XML isn't an issue. When we do - in a future release - we could include multiple enclosure elements in the XML, or create an extension (or leverage the Yahoo Media RSS extensions). At the end of the day, I'll readily admit that complex Atom 1.0 feeds won't look pretty in RSS 2.0+Atom-extensions. That said, the vast majority of all Atom feeds on the Internet today convert to RSS 2.0 with zero issues. I'll repeat what I said in a different response: This isn't the end of the API set, and this feedback is useful to figuring out what needs to happen for the next version. Thanks, Sean -Original Message- From: Sam Ruby [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 5:32 PM To: Sean Lyndersay Cc: Atom Syntax Subject: Re: Fwd: [rss-public] Microsoft Feeds API Enclosure Test Sean Lyndersay wrote: The normalized XML that you're seeing in View Source is also accessible from the feed APIs, so the XML we generate is a format we expect to support in perpetuity. It's designed to be a relatively simple format that application developers can rely on in the same way that they rely on APIs in the object model, so we map all common elements from other formats into RSS 2.0 (the basis for our native format). Why RSS 2.0? Because it's the format used by the majority of feeds on the web. From reports I have seen, you are doing things like adding type attributes on the description element? If so, it isn't RSS 2.0. How do you plan to handle multiple enclosures? How about HTML in titles? On Feed-Tech I saw a post by Phil Stanhope indicating the importance of sub-second times in certain scenarios. How will this be expressed in RFC 822 format? How about content that is in a binary format? I can go on... Any case of data-loss is a bug that we'll address If that is a blanket statement, then I expect that you will be seeing a lot of bug reports. - Sam Ruby
RE: finishing autodiscovery, like now
On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote: The spec is extremely well-written [...]. Heartily concur. On Jan 24, 2006, at 10:09 AM, Tim Bray wrote: +1. Ship it. -Tim +1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray Sent: Tuesday, January 24, 2006 10:09 AM To: Robert Sayre Cc: Atom Syntax; Phil Ringnalda; Mark Pilgrim Subject: Re: finishing autodiscovery, like now On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote: PaceAnchorSupport and PaceDifferentRelValue don't seem very useful, and they weren't proposed by implementors. The spec is extremely well-written and reflects existing behavior. Can we please un-expire this: http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html and be done? +1. Ship it. -Tim -- Robert Sayre I would have written a shorter letter, but I did not have the time.
