[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")
I've been testing IE7 beta 2's support for Atom, with the following
Also here for easier viewing in IE7
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.
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.
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
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?
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 link@rel 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="http://www.iana.org/assignments/relation/alternate" should be
treated the same. The same goes for enclosures. See the entry: "Entry
with full iana link@rel 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
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
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
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
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
Apart from those problems it looks pretty good.