• Too much indirection when attempting to discover information about the services a site supports. I have to hit the website's homepage which has a LINK element which points to an RSD file which to an introspection file that describes the features supported by the website before I can figure out which Atom API services teh website supports. At least one of those steps is unnecessary. I don't see why the link element can't directly point to the introspection file.
  
  
• There is no description of which Atom API services are required to be supported and in fact the current text implies that one can support as few features as one likes. Although this seems to offer maximum flexibility for certain sites such as sites that don't support editing your blog posts like K5 or sites that only want to provide one feature (e.g. Google/Yahoo/MSN allow to search from your news aggregator) it does mean there might be a certain degree of inconsistency which users may not like.
  
  Maybe a good idea would be to cluster features together in the way the W3C DOM clusters functionality into levels 1, 2 and 3.
  
  
• Both the examples for creating a new entry and editing an existing entry show the client sending the created and modified dates to the server. This seems wrong from my perspective. The server should be the one stating when an entry was created or modified not the client.
  
  What happens if I started working on a post last week but only send it today, which created/modified date do I send to the server?
  
  
• Things like setting user preferences and templates seem to differ very widely between blogging products. Is there any point in trying to standardize this since it highly likely that each piece of blog software would have custom extensions to whatever format for setting templates or user information is decided on?
  
  There are some assumptions in the section on editing templates that seem to not necessarily be true. The first is that each template is accessible as a network retrievable file and another is that there is a one to one mapping between templates and pages on the weblog.
  
  
• If you're going to have features like setting user prefs and templates, why not have a way to set the user's blogroll? I've seen many people complaining that the blogroll on their website doesn't accurately represent the feeds they are currently subscribed to in their aggregator. The ability to send one's blogroll direct from the aggregator would be a nice optional feature.
  
  

I'm looking forward to seeing how the missing parts of the spec will shjape up as well as what the spec for the SOAP version of the ATOM API will look like.

--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.