intertwingly

In (very preliminary) investigation it appears that Google assigns its own item IDs.  It does preserve the original ID in an attribute on the id element, though... not sure how kosher that is.

They’re not difficult to explain at all, and they seem consistent with the notion of “fallbacks” that feed validator denizens are so fond of. That is, an extension element is usually a gesture by the author that indicates a preferred location for some genre of information, and Atom processors that want to have a market share should operate similarly. I think I would prefer pubDate over dc:date as well... the semantics of dc:date are too fuzzy.

Ultimately, you have to make a best-guess interpretation for any sufficiently popular Web format. I do like to think the Atom format makes that a little easier, but I’m not sure why that makes the protocol worth waiting for.

If I were given an API that professed to be based on RSS 2.0, and I saw an Author property or method, my first assumption would be that it would try to return an email address whenever possible.

Like Dave, I would have preferred something like the Atom person construct over silent data loss.  But unless this API is ported to Ubuntu, I’m unlikely to ever use it.

“Worth the wait” was a quote from Dave.  It referred neither to MS API, nor the Atom protocol, but to the book.

"my first assumption would be that it would try to return an email address whenever possible."

And, after processing a few feeds, noticing that some didn’t have an email, some were RSS1, and some were Atom, what would your opinion be, as a producer of end-user software?

And, after processing a few feeds, noticing that some didn’t have an email, some were RSS1, and some were Atom, what would your opinion be, as a producer of end-user software?

That a person construct consists of a separate name, uri, email, and extension_elements properties.

Oh I see, the docs are wrong. Here’s another page that doesn’t have the same error. It’s “a string”. I think that’s about all they can promise. If the argument is that they should normalize to Atom instead of RSS, I just don’t sympathize.

Also, they probably feel, however irrationally, that Atom is controlled by their competitors.

Blah, blah, blah...Microsooft is evil and incompetent...blah, blah, blah.

I made a bunch of the same type of decisions in RSS Bandit. I can’t even remember right now if I always preferred “funky RSS” to core RSS elements but I’m pretty sure I do in at least some cases. I guess I’m evil and incompetent as well.

The only example that is clearly a bug is the last one, where the feed has atom:summary and atom:content but Microsoft’s feed parser only exposes atom:content.  The more general issue here is what to do about weird combinations from different specifications or extensions.  God knows I’ve struggled in UFP with exposing description, atom:summary, atom:content, itunes:summary, content:encoded, and xhtml:body (not to mention rss091:description, CDF’s abstract, and Jon Udell’s fullitem) in some relatively sane manner — all of which can appear in combination in virtually any feed.  In fact, I’m still struggling with it, and in 4.2 I will be adding a ‘source’ attribute to the parsed content dictionary to identify which element a particular piece of content came from (hat tip: Kevin Marks).

But atom:summary + atom:content isn’t an edge case; it’s the trivial case.  Both well-defined, both from the same spec.  I wouldn’t call it incompetence.  It’s a bug; fix it.

I’m seeing lots of interest in my MS Feeds API post yesterday, sparked by links from Sam Ruby, Dave Winer and Randy Morin. Some people might have gotten the impression that I was criticizing the decisions MIcrosoft made in mapping RSS elements and...