There's been a bit of a thread going round in one circle of the blog-space lately following a somewhat flawed post from Dare Obasanjo about the Atom Publishing Protocol (APP). Putting a phrase like "...[Microsoft] will likely standardize on a different RESTful protocol" early in a post is bound to get the attention of anybody who is concentrating. It just sounds so much like the typical Microsoft result of not using existing standards and reinventing poorly.

Developments since then have been interesting and it provides an interesting case study in the use and abuse of technical specifications.

(Read more...)

Topics: technology/xml/atom, software/design

[#]

Syndication has become important over the last few years. Sure, it's been around for a while, but these days it's almost at a point where I could see my parents using it — OS installations are shipping with feed readers, third-party apps are readily available and the feeds themselves are pretty standard on many "updatable" sites.

That being said, having ubiquitous feeds throughout a site is not a universal trait. If creating a feed is any real amount of work, it means you have to actually design the feature and work out where you want feeds. If creating feeds is simple and somehow built into your toolkit (whether your toolkit is a bunch of common libraries, or a framework, or just the knowledge in your head) then you are going to be more inclined to put them everywhere you can.

I was recently thinking through how to integrate some feeds and some Atom publishing entry points in a site I am working on and I arrived at what I suspect is already common knowledge: each new piece of metadata is a potential feed. So if you classify things by author, then there could be a feed per author. If you (also) have tags, there is a potential feed per tag, and so on. Even in places where I thought this didn't quite make sense, it ended up being useful. A feed per day or per permalink? Sure — it includes the article, plus any comments and updates. Not everybody may want such a feed, but it costs nothing to include it (if you're clever) and for those who might like to consume your data that way, why not help them out?

Coincidental confirmation that this kind of mapping is useful arrived yesterday evening: Dave not unreasonably called me out for not taking many photos of where I live. This led me to wonder what other people had done around here (home) and looked up the area via Flickr tags. Well, sure, there are some useful tags such as pc2077 and hornsby. There is also a feed on each of these pages so that I can track any updates. Obvious enough, but not every website does this and Flickr has enough rough edges that I was briefly surprised they'd got to this point. Nice one, Flickr.

Topics: technology/xml/atom, photography/flickr, technology/metadata, thinking

[#]

I learnt something today. Actually, I think I learnt it again; for about the tenth time.

The hidden advantage of a well-written specification is that you can read it without needing to be aware of all the drama that went into creating it.

In this case, it was the Atom Publishing Protocol specification. Reads well on the outside; looking under the covers was depressing, though.

(Read more...)

Topics: technology/xml/atom

[#]