April 12, 2006

Wretched Syndication (RSS)

12 April 2006 Regulars know that I think Syndication Feeds are the best thing to come along since the WWW. It has taken some time for the Feed phenomenon to hit the mainstream, but now companies such as Microsoft and Google are gearing up to provide mainstream services using Feeds for both business and consumer audiences. By the way, you'll hear a lot of people using the term RSS, which stands for something, somewhere, but calling them Feeds is more, ahem, politically correct. Anyway...

Feed Icon
It would be good for some of us to agree on how to subscribe to feeds and how to display their capability. Diversity is good, but not when it comes to confusing novice users, let alone experienced ones. After years of using (and creating) weblogs, I often still have difficulty finding a Feed or selecting one which best suits my needs. Jeff Veen seemed to care before Google bought the product he was working on, but I've not heard much about it since. Sam and Rogers, Mark and Tim, are there some recommendations we can implement? Or shall we just wait for Microsoft to set the standard?

[A special note to Mark who has just started up his Weblog again: Are you suggesting to leave it to the browser to show that you have Feeds available?]

Posted by Marius at 01:00 PM | Comments (0)

August 19, 2005

Building a feed for our calendar

19 August 2005 This week we'll describe two ways to build a feed which can be used to disseminate the events calendar which we built last week. The easy way to build a feed is to use a Weblogging tool such as Movable Type. Simply build a weblog with only one entry which we'll update regularly to give us the two months rolling calendar. Movable Type does all the hard work, and all we'll do is cut and paste the calendar information into it. You can see how that might look here. And of course, the entry is made available as a feed automatically by Movable Type.

For those who are interested in what a feed really consists of, let's also build one manually.

A feed in its simplest form is a file with a specific format, in our case, RSS 2.0. While there are other formats (such as Atom), for the moment, RSS 2.0 is the most common. It is quite a flexible format and as you'll see it is not that difficult to create.

RSS 2.0 feed dump
First there are the XML and RSS pre-ambles:
<?xml version="1.0" encoding="UTF-8"?> <rss version="2.0">
Everything happens in a "channel":
<channel>
Give the feed a title and link to the parent page:
<title>Tax Due Dates</title> <link>http://www.activeweb.com.au/index.php?option=com_ content&task=view&id=18&Itemid=28</link>
Describe the feed:
<description>Due dates for Australian Tax Office submissions and payments</description>
The language it's written in (Strine):
<language>en-AU</language>
The way it has been generated:
<generator>Hand-coded</generator>
A link to the RSS spec:
<docs>http://blogs.law.harvard.edu/tech/rss</docs>
Ask to be read no more often than every 60 minutes:
<ttl>60</ttl>
At last, this is where we get down to business. A fee can have more than one item, ours only has one.
<item>
For us the title of the item is the same as the feed's title:
<title>Tax Due Dates</title>
The feed represents the event calendar at:
<link>http://evdb.com/calendars/1691</link>
And here is the payload of the feed:
<description> This is where we put our Calendar data </description>
Here is the publication date of the item:
<pubDate>Mon, 15 Aug 2005 17:00:00 +1000</pubDate>
Every feed needs a globally unique identifier, we'll use the feed's URL for that.: <guid isPermaLink="true">http://activeweb.com.au/cal/taxfeed.xml</guid>
</item>
Here is the publication date of the feed:
<pubDate>Mon, 15 Aug 2005 17:00:00 +1000</pubDate> <lastBuildDate>Mon, 15 Aug 2005 17:00:00 +1000</lastBuildDate>
And close the "brackets"
</channel> </rss>

The full feed can be seen here .Of course, we would not normally create this manually. Using a tool like Movable Type or doing it programmatically is a much better option. The purpose of doing it manually here, was to take the magic out of it and show how it's done.

Posted by Marius at 11:57 AM | Comments (0) | TrackBack

August 12, 2005

Building our Tax Calendar

12 August 2005 Last week I promised to follow up on my quest to find a practical solution for building an online events calendar. Something like the one on this site, but with a convenient way of building a list of events, regularly feeding it to the web site and giving users a simple way of importing the events into their calendar (hopefully, not just Outlook).

A good way of thinking of the Web today is as "small pieces loosely joined". We'll therefore try and build the calendar without writing any code, using readily available standards, software components and services.

The calendar should be easy to update remotely. Using RSS means that a feed will periodically update the calendar on the site, while also giving users the option of getting updates without going to the host web site. The Mambo CMS which is used on the current website already has a component which accepts RSS feeds, so that issue has already been solved for us.

Despite the fact that commentators feel that calendar interoperability is a train wreck, for the moment, RFC2445 is what we've got and hope that we can make a simple application like this work without re-inventing the wheel. As it happens, there is an event database , EVDB, which already exists, uses existing standards and does almost everything we require.

EVDB site showing tax calendar

While it is tuned for time & place style events, it wasn't hard to enter the events and build a calendar with the tax dates. EVDB already has ICAL and RSS exports, so it looks like we have our solution. Unfortunately, a few practical issues get in the way. We're looking to build a feed which simply lists all due dates for a rolling two month period, rather than individual posts as they are created. EVDB features a developer API to access the database and build whatever we like, but for the purpose of this exercise, we want do this project without programming.

The little ICAL button on EVDB's individual entries, however, implements the import feature just like we would like to use in our calendar. It allows us to download that entry or import it directly into a calendar. Looking at the content of the file, we see it is pretty straight forward:

BEGIN:VCALENDAR
METHOD:PUBLISH
CALSCALE:GREGORIAN
PRODID:-//EVDB//www.evdb.com//EN
VERSION:2.0
X-WR-CALNAME:EVDB Event Feed
X-WR-RELCALID:evdb
BEGIN:VEVENT
DTSTART:20050921T220000
DTSTAMP:20050808T041617Z
SUMMARY:Monthly BAS and IAS
DESCRIPTION:Payments for August 2005 due.
SEQUENCE:0
UID:E0-001-000282349-5
END:VEVENT
END:VCALENDAR
In principle, we have a solution:

Now that we've built the calendar, next week we'll find a practical solution for building a RSS feed.

Posted by Marius at 11:39 AM | Comments (0) | TrackBack

July 07, 2005

Apple's standard

[7 July 2005] Microsoft recently suggested an extension to an important emerging standard, RSS. They used a grass roots industry conference to discuss their extension before shipping any product which used it and quickly received comprehensive, constructive feedback from a range of smart people. To Microsoft's credit, they have come to understand that by opening themselves up to (sometimes painful) scrutiny, they end up creating better products.

In contrast, Apple's recent Podcasting extension to the same RSS standard was shipped in the latest version of iTunes without consultation. And it looks like a rush job,  getting a lot of criticism from those who care about these things.

Standards in software are important. I want my email to be read by anyone without worrying what software or hardware they have. Standards used to be created either because acompany became dominant in a particular market (for example Microsoft Word) or were derived by a standards body (as in telecommunications). By contrast, standards on the Internet are more likely to evolve through community consultation. Someone suggests a standard or an extension to one and invites comments. While the process of getting concensus may sometimes be painful, it also makes for better, universal standards. And respect for those who engage in the process.

Posted by Marius at 06:08 PM | Comments (0) | TrackBack