Blogging Roller

apache apachecon app apple asf atom atomprotocol atompub barcamprdu blogapps blogging businessblogging conferences family feeds foss general glassfish google humor ibm java javaone links linux mac microsoft movies music netbeans opensocial opensource photos politics rest roller rome rss socialnetworking socialsite socialsoftware sun triangle trianglebloggers vacation webdev webservices wiki

1. There's zero ambiguity about single and double escaping, you can 
   use whichever suits your publication process better and not worry 
   about silent data loss.
2. You can include binary chunks right there in-feed, base64 encoded.
3. You get help for aggregate feeds using atom:origin
4. You have a date, atom:updated, with cleanly-specified semantics 
   ("publisher says something changed") that's *guaranteed to be there* 
   per-entry
5. It's in an XML namespace
6. It's got a good accessibility story: you have to have an atom:summary 
   if there's no src= or it's binary.
7. You have clean semantics for linking to the entry this describes or 
   the entry it's talking about.

Personally, I think these are highly significant. But even if you 
disagreed, there are two other reasons why it would be good to get the 
Atom format spec finished:

1. Atom has an official specification change-controlled by a 
   highly-independent standards org, there is no suspicion that any 
   vendor or individual is pulling the strings. This might not strike you 
   as important, but I assure you that there are lots of people to 
   whom it is.
2. The atom format is one foundation of the Atom publishing protocol, 
   and I guarantee that the world can *really* find a use for the protocol.