Wednesday, March 22, 2006, 5:13:05 AM, M. David Peterson wrote:
> Hey Folks, > > With yesterdays build release of IE7, it seemed appropriate to run > a quick inventory check to see where things stand in regards to the > derived MS/RSS conversion of a fairly element/attribute usage > heavy Atom feed. Here's the overall breakdown. > [...] > Beyond this, it seems that everything else *SHOULD* be able to map > back fairly well. There haven't been many changes to the transformation process in this build, so all of the 15 issues with the Atom transformation in the old build are still issues with this one. http://www.imc.org/atom-syntax/mail-archive/msg17898.html [Quick summary of actual data-loss: loss of person extensions, loss of timezones/corruption of times, loss of [EMAIL PROTECTED], titles are flattened to text without preserving HTML version, loss of category label, xml:base/xml:lang loss, inheritance of atom:author and atom:rights not handled ] The last issue perhaps needs some more explanation: In Atom, the following two entries are equivalent: a) <atom:feed> <atom:author><atom:name>David Powell</atom:name></atom:author> [...] <atom:entry> [...] </atom:entry> </atom:feed> b) <atom:feed> [...] <atom:entry> <atom:author><atom:name>David Powell</atom:name></atom:author> [...] </atom:entry> </atom:feed> The same inheritance also applies to some other elements such as atom:rights, and xml:base/lang suffer similar issues. Superficially it seems that there is a problem with IE7s rendering, in that <http://www.tbray.org/ongoing/ongoing.atom> doesn't display Tim Bray's name next to the entries. But, actually the problem is deeper than that. Because you only preserve the latest instance of feed metadata, if it was up to the client of the API to examine the feed author, and manually inherit it every time it wanted to display the author of the entry, then the entry would inherit the wrong authors if the feed author had been changed since the entry was polled. Eg: feed producing code may put atom:author only on the feed unless there are multiple entries in the feed with different authors when it would add it to the entries too. Basically you can't require the client of the API (eg IE7) to perform the inheritance, because they need to inherit the author from the feed document as it was when the entry appeared in it, not as it is now. The solution, I expect, is to copy any elements that should inherit down into the entry during the normalisation process. That way the display of Tim's feed gets fixed, clients don't need to worry about inheritance, and author and rights attributions of old entries don't get mangled by future modifications to the feed document. Ideally you should perform inheritance from atom:source too, as described in the RFC. > The areas that are currently untested, and potentially a point of > concern (that I can think of off the top of my head, anyway) > > * undefinedContent of element atom:category I think it is perfectly reasonable to discard "undefined content" (such as namespaced attributes on Atom elements). If you want an extension, use an extension element. If you want to sprinkle attributes everywhere in the assumption that implementations are going to preserve whatever document you pass to them verbatim - well, don't be too disappointed. > * any extended usage of xml:base and xml:lang Proper preservation of these two is essential. In particular the baseURI for each feed needs to be preserved after resolving it relative to the document URI (and Content-Location if you're after extra credit); the baseURI for each entry needs to be preserved after resolving it relative to the baseURI for the feed. The baseURI for entries needs to be stored independently of the feed metadata, otherwise redirecting the feed, or changing its base, will retroactively break the baseURIs of older entries. > atom:published atom:published isn't preserved as an exact copy. It is converted to an RSS style date (with the time as-is, and the timezone set to GMT even if it wasn't). > Overall it seems to me the MS/RSS team has done a pretty fantastic > job of ensuring a fairly high quality conversion, making exact > copies of those elements and their associated attributes that did > not allow for a clean conversion to the MS/RSS format and still > maintain any hope whatsoever of making the round trip back to its > original Atom format. Here here! With all of the high-profile coverage of RSS in the publicity, I was expecting Atom to be either neglected, or supported with much lower fidelity than it is now. Most of the data-loss problems are minor (and therefore easy to fix :). The serious problems are with inheritance (xml:base, xml:lang, atom:author, and atom:rights). -- Dave
