I’ve just finished writing part 3 of my series about DataRSS. Part 1 gives the background and justification for the concept, and Part 2 worked through a semi-believable scenario where having DataRSS would be a good thing.
In part 3 I try to get into more technical detail. I hope that you take the time to read it because that’s the only way I will get technical feedback on it. The reason I wrote the first two parts is that realistically I expect to lose 99.5% of you guys once you open up part 3. That’s why this post is labeled [GEEKY]. Here’s some of what I cover in part 3:
“Data RSS is a simple protocol and a simple data format. It can be implemented in any programming language.
Importantly, the Publisher and Accessor software need not know (can not know) what language the counterparties software is written in. ” (from DataRSS: Technical Overview)
“DataRSS is used between two parties, the Publisher, who ‘owns’ some data, and the Accessor, who wants to use that data. Publisher and Accessor are organizations with people in them. The Publisher wants to offer a technical means to allow an application program simple and standardized access to their data.
The Accessor wants to write an application program that accesses and does something useful with data coming from any Publisher. Accessor and Publisher don’t know each other. ” (from DataRSS: Technical Overview)
Delicious isn’t it? One final tease, I also have worked out some detailed examples of how DataRSS might work with the New York Times API, with the Sunlight Foundation API and with the Follow The Money API.