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 entry needs to store the xml:lang and xml:base context at the time it was last seen in the document. I think that if a document has xml:lang set on atom:feed, then this attribute should be written to all item elements, unless it is overridden on that atom:entry element. Same for xml:base, except you might need to resolve the entry base against the feed base. Actually if you support feeds redirecting at the HTTP level, then you probably ought to always write the xml:base (and ensure that the feed URI is taken into account when generating it), else relative images and links will break after the redirection. Rewriting known elements such as atom:link to use absolute URLs based on the xml:base context is not an acceptable solution because you don't know which extension elements might contain URIs. 14. Inheritance of atom:author and atom:rights atom:author and atom:rights should be taken from the entry if available; else from ./atom:source/atom:author and ./atom:source/atom:rights; else from /atom:feed/atom:author and /atom:feed/atom:rights. Currently this inheritance doesn't happen, so unless you put atom:author on every entry, it doesn't get recognised. I suppose you ought to write these feed level elements to the item in all cases else when they change at feed level they will erroneously get retrospectively inherited to entry level. [Personally, I think feed/entry inheritance is a PITA, but that is how it works. Interference would be a better word for it. ] 15. Effect of xml:base on content xml:base affects links, but doesn't seem to affect links and images in HTML content. Kind of tricky to fix, perhaps you could run some javascript over the content to fix-up all of the src's and href's. Apart from those problems it looks pretty good. -- Dave
