intertwingly

I don’t want to be too critical since they are still in development, but I think they have a long way to go. The feedvalidator doesn’t (understandably) catch all of their errors.

For example, there’s the “parent” link that they add to every entry. Its href is a “feed” uri (already a big mistake) that has been percent-encoded. To the feedvalidator that looks like a perfectly valid relative uri, but I’m fairly sure that’s not what it’s meant to be.

Try a feed with a feed-level author element but no entry-level author elements. They throw out the feed-level author and introduce an “unknown” entry-level author. Perfectly valid Atom, but a corruption of the original data.

Try a feed with xhtml content. They convert it into type="application/xhtml+xml" with escaped html. Once again, perfectly valid Atom, but the original data is completely corrupted.

And then there are all the rest of their basic title/content parsing errors that lead to silent data loss and data corruption. If Google Reader can’t read it, you can be fairly sure the Google Reader API is going to corrupt it.

Let’s just hope things improve between now and next month.

Let’s just hope things improve between now and next month.

So far, I’m impressed in the level to which they accept bug reports and participate in discussions.  Seeing Chris and Mihai talking publicly gives me reason for hope.

James, thanks for the feedback. Some responses:

The parent href value is meant to be a relative URL (it’s not a feed: scheme URI, it’s a feed/ partial URL that can be used with http://www.google.com/reader/atom as the root).

The feed-level author element being ignored is indeed a bug. I will look into getting this fixed.

We normalize all content data to entity-escaped HTML, so that’s intentional. What is a bug is the type being left as XHTML.

My apologies. I foolishly mistook the %2F in the parent link for a %3A.

However, if you want those relative URIs to work you need to make it very clear which parts of the query URI need to be escaped. For example, all the examples that Niall gave would have resulted in a root of http://www.google.com/reader/atom/feed/.

Obviously it’s not your fault that he formatted the query incorrectly, but you may want to consider returning an error when that happens rather than processing the request as if it were valid and returning an invalid feed.

As for normalizing the content data to HTML, I tend to think that’s a good idea considering the level of support for inline XHTML in Atom. However, I suspect you’ll find a number of XML proponents who will be vehemently opposed to such a conversion. You have my sympathy. :)

Sam Ruby: Google Reader API....

[link]...