Thanks to Danny Ayers post entitled Attention, Attention.xml I finally found a link to the attention.xml specification that was referenced in Robert Scobles post Gillmor's report on Attention.xml is done where he wrote
One of my 2005 predictions is coming true. Steve Gillmor's report on Attention.xml is included in Esther Dyson's Release 1.0. Thanks to Mike Manuel for letting us know the report is now available for $80. I'll have to check our corporate library and see if it's available there (I believe it is).
Danny Ayers does a good job of taking a critical look at the syntax chosen for the attention.xml format. I on the other hand, have fundamental questions about the purpose of the format and how it expects to solve the problems highlighted in its problem statement. As at the time I wrote this post the attention.xml problem statement stated
How many sources of information must you keep up with? Tired of clicking the same link from a dozen different blogs? RSS readers collect updates, but with so many unread items, how do you know which to read first? Attention.XML is designed to to solve these problems and enable a whole new class of blog and feed related applications.
How many sources of information must you keep up with?
Tired of clicking the same link from a dozen different blogs?
RSS readers collect updates, but with so many unread items, how do you know which to read first?
Attention.XML is designed to to solve these problems and enable a whole new class of blog and feed related applications.
These are rather lofty goals and as the author of a moderately popular RSS reader I am interested in solutions to these problems. Looking at the attention.xml format schema description it seems the format is primarily a serialization of the internal state of an RSS reader including information such as
This list of data seems suspiciously like a format for synchronizing the state between multiple aggregators or an aggregator client and server. This makes it very similar to the Synchronization of Information Aggregators using Markup (SIAM) format which I authored with input from a number of aggregator authors including Luke Hutteman (author of SharpReader), Morbus Iff (author of AmphetaDesk) and Brent Simmons (author of NetNewsWire).
Before going into some of the details around the technical difficulties in recording some of the information that the attention.xml format requires I want to go back and address the problem statement. I can't see how the internal state of an RSS reader serialized to some XML format solves problems like users seeing multiple blogs posts from people linking to the same item or determining the relative importance of various unread items in a users queue. The former can be solved quite readily by aggregators today (I don't do it in RSS Bandit because I think the performance cost is too high and it is unclear that this feature is actually beneficial) while the latter is bordering on an AI problem which isn't going to be solved with the limited set of information contained in the attention.xml format. In short, I can't see how the information in an attention.xml document actually solves the problems described in the problem statement.
Now on the technical and social difficulties of creating the attention.xml format. The first problem is that not every aggregator can record all the information that is required by the format. Some aggregators don't have post rating features, some won't or can't track how long a user was reading an item [which will vary from user to user anyway due to people's different reading speeds], and others don't record the user's relationship to the author do the feed. So attention.xml requires a lot of new features from RSS readers. Assuming that the spec gets some traction, I expect that different aggregators will add support for different features while ignoring others (e.g. I can see myself adding post rating features to RSS Bandit but I doubt I'll ever track reading times) which is the case with support for RSS itself within various RSS readers today. The fact that various RSS readers will most likely support different subsets of the attention.xml format is one problem. There is also the fact that logging all this information may be cumbersome in certain cases which would also reduce how likely it is that all the information described in the spec will be recorded. Then the problem is what to do when clients speak different dialects of attention.xml. Are they expected to round trip? If I send Bloglines an attention.xml file with rating information even though it doesn't have that feature, should it track that information for the next time it is asked for my attention.xml by Newsgator which supports ratings?
Don't take this post to mean that I don't think something like attention.xml isn't necessary. As it stands now I want to increase the number of synchronization sources supported by RSS Bandit to include the Bloglines sync API and Newsgator Online synchronization but they use different web services. It looks like Technorati is proposing a third with attention.xml. I'd love for there to be some standardization in this area which would make my life as an aggregator author much easier. Client<->server synchronization of user subscriptions is something that users of information aggregators really would like to see (I get requests for this feature all the time) and it would be good to see some of the major players in this area get together with aggregator authors to see how we can make the ecosystem healthier and provide a better story for users all around.
I don't believe that attention.xml is a realistic solution to the problems facing aggregator authors and users of RSS readers. I just hope that some solution shows up soon as opposed to the current fragmentation that exists in the syndication market place.