Okay, I just now figured out what David Winer was referring to over at scripting when he mentioned “funky RSS” while discussing my efforts here. SO, here is the “not as funky” version of my proposed RSS 2.0 for the IBS. It’s still a bit funky because it still extends with the alternate links, but as I stated above, there is both a technical and business reason for this:
Thanks Dave, this is exactly the type of issues I wanted to hash out online.
In the Beginning
“I don’t care who’s fault it is, I’ll knock both your heads together” is what my father used to tell us when my brothers and I would get into each other. We love each other dearly, but like any sibling rivalry, there’s always some friction while both parties are living under the same roof. Now we live in different houses with different lives. We miss each other and truly enjoy ‘short‘ vacations together. Note the emphasis on short.
This pretty much sums up my feelings about the RSS vs. Atom debate. A ‘religious war’ that I’ve ignored up until last week, when I decided to volunteer a healing hand to the not-so-valid RSS feed for the International Bible Society’s (IBS) Daily Manna Verse of the Day. In the process I found myself having to spend twice as much time, producing two different syndication files that deliver the exact same data. More on that after we walk through my proposed modifications.
At the lowest level, we need the scripture reference and a hyperlink to an online Bible or devotional. Optionally, we’re likely to want direct access to the text to the passage, with a handy a reference back to the copyright owner. And if you’re like me, we’ll need the ability to present and format the data so it best fits the look, feel and validation specifications of your website.
The current IBS:DM RSS file fails in that respect. But there is a valid business reason for this attempt. It’s called branding. The next time you buy a Bible, the IBS wants you to buy it from them. So one of the other objectives needs to satisfy this aspect of the content and it’s provider.
Another fun feature of the IBS:DM syndication file would be to offer one, perhaps two weeks worth of verses. Not only would this make some church website owners I know happy, but this feature would also help distinguish the IBS from it’s competitors.
Starting at the RSS::<item> , Atom::<entry> level:
Working our way up the hierarchy from the inside, the first thing we need to do is scoop out the redundant data, such as the product title and the main website address and put it aside for incorporation at the RSS::<channel> , Atom::<feed> level. What is left is exactly what we want, a scripture reference for the title. Unique and ready to publish on our websites. In English:
Next, taking a page out of Steve Krug’s “Don’t Make Me Think,” we offer a hyperlink to the IBS’ own daily archive link. This way we link to content specifically cited in the <title> tag while retaining the branding the publisher seeks.
Finally, we either needed to encapsulate the RSS::<description>, Atom::<content> with <![CDATA[ ... ]]> to accommodate the hyperlink to the audio rendering, or figure out some way of listing the audio version as an alternate link.
Since the audio hyperlink in the current IBS:DM RSS isn’t all that XHTML compliant, it’s probably better that we use an RSS format that can be extended with namespaces. By declaring the Dublin Core’s Link Module namespace (xmlns:l=http://purl.org/rss/1.0/modules/link/) we not only gain the capacity to create a node for the audio version, but for also for those who would prefer to hyperlink to the BibleGateway.
This offers three advantages.
- it reinforces the IBS brand as the average user with the average aggregator will opt to go to the easy to use IBS link.
- capable programmers (who would otherwise scrape), can reuse the same parsing mechanisms for both the audio and Bible Gateway alternates
- this particular extension can be plugged directly into the Atom syndication file without modification.
I suspect that it is on this third point that we’ll get the most debate. One of the distinguishing aspects of Atom is that you can list several <link> elements within a single <entry> node. However, I like how the Dublin Core approach buys programmers on both the producer and consumer level some code re-use while protecting the IBS’ branding.
Finishing up on Top
At this point, we have our individual nodes of titles, links, content/descriptions. All that’s left now is to take all that redundant data that points back to the main IBS:DM page and shove it into the RSS::<channel> , Atom::<feed> level.
Publish, and pray the good folks at the IBS replace old wineskins for new. That is after YOU get busy taking a look at my proposed files:
- Proposed RSS 2.0 Daily Manna Syndication Feed File
- Proposed Atom 0.3 Daily Manna Syndication Feed File
- A version of the Atom 0.3 file that employs multiple <link> elements instead of employing the Dublin Core Link Module namespace
Same data, formated several different ways for essentially the same purpose, syndication. Will it always be this way? I can’t say. Competition can be beneficial as it causes both parties to ‘up their game.’ That said, from a programmer’s perspective I’m not too keen on having to support such a ‘wide variety of standards.’ Blame it on my reusability and reliability theology.
Enough preaching. I know there is a barb for the KJV only camp in there somewhere, but I’m too pooped to care about it. Instead, please check out the files. Got questions, concerns and/or corrections? Leave a love note in the form of a ‘constructive‘ comment. Note the emphasis on constructive.