Subject: Re: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")

From: David Powell <[email-masked]>
Date: Wed, 1 Mar 2006 19:33:21 +0000

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 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="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 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
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

---

From: Sam Ruby <[email-masked]>
Date: Wed, 01 Mar 2006 18:21:56 -0500

> I think that the date format should be kept as-is in ISO8601-style

Why is atom:updated converted to pubDate?  If any atom date is converted
to pubDate, why isn't it atom:published?

- Sam Ruby

---

From: Sean Lyndersay <[email-masked]>
Date: Thu, 2 Mar 2006 12:04:20 -0800

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-masked]]
Sent: Wednesday, March 01, 2006 11:33 AM
To: Sean Lyndersay
Cc: [email-masked]
Subject: Re: IE7 Atom Handling (was RE: Link rel attribute "stylesheet")

Hi Sean,

01. Person Extensions

02. Timezones

03. atom:published

05. HTML titles

06. atom:generator

09. Category label

10. xml:base everywhere

12. Subscription name

--
Dave