Uncooked: Life, the Universe and Feed Subscription

« Folk semantics | Main | For Sparql Fans »

Life, the Universe and Feed Subscription

Ok, here's my €0.02 on the one-click feed subscription issue. The first €0.01 is that it shouldn't be necessary for people to put other people's icons on their page. None. Imagine the Beatle's White Album with an orange [XML] in the corner... Clients only need to be a tiny bit smarter, use autodiscovery to pick up the <link> elements and make an appropriate offer to the end user. FireFox is well on the way with this.

For the other €0.01, where links are provided, the server can help by pumping out the feed with the appropriate mime type. From what I've heard this is likely to happen out of the box in many cases with Atom. Given an appropriate mime type, there's no need to use pseudo-URI schemes like feed://. Almost. There is another small piece of the puzzle that's missing, at least for RSS 2.0.

Providing a link to the feed itself within the feed, for the client handler app to pick up. RSS 1.0 should provide this already, as the channel resource. (I just noticed that TypePad at least gives the URI of the (HTML) blog instead, oops. Atom does in... does it..? Time for a post to list...) For RSS 2.0 this problem can be solved by adding a namespaced element which points to the source feed. Ok, so you still have the problem of not being able to use the mime type in most cases. But I have a cunning plan. What if people are encouraged to add a stylesheet reference to there feeds? i.e.
<?xml-stylesheet type="text/xsl" href="rss2html.xsl"?>
The stylesheet itself could be on the local server or on some friendly person's. The XSLT would render the feed in a human readable fashion, with a note saying "this is a feed" and then a set of links for either subscribing to a client- or server- side tool. Those links would be derived from the extra element pointing to the feed. This solves the problem of not being able to serve with a registered mime type, as well as presenting the end user something useful rather than a page of code.

January 14, 2005 in Web/Tech | Permalink

Comments

Danny - Can XSLT work over multiple servers? I thought that it had to be a local reference, for security reasons: You can't use a remote xslt stylesheet, in the same way you can't load javascript from other domains...

I could be wrong though, just what I thought.

Of course, since there's no email notification, I'll never see a response to this.

Posted by: Christopher Schmidt | January 14, 2005 at 11:37 PM

Hey Danny. Trying not to sound like a plug, but that's what we're trying to do with the FeedBurner "Browser-Friendly" service: apply an XSL style sheet that provides some ways to subscribe to that feed and describes what exactly a feed is.

Christopher: very true ... your XSL stylesheet has to be from the same domain as the XML document. FeedBurner gets around this by being a proxy for the feed, so it is the same domain!

Posted by: Eric Lunt | January 15, 2005 at 03:38 AM

Oh, that's a pain, I didn't realise that.

Eric, what's the current status of your service? I'll be happy to give it a plug.

re. mail notification - heh, I only just realised. I was wondering, I usually have one comment in my inbox.

Posted by: Danny | January 15, 2005 at 10:44 AM

FeedBurner is pretty good.

For example, my blog only has an atom feed (I run on Blogger), but here's my human-readable RSS 1.0 feed: http://feeds.feedburner.com/pip/rdf

or my atom feed with my Flickr photos and del.icio.us bookmarks spliced in: http://feeds.feedburner.com/pip/all

It's very very handy.

Posted by: Phil Wilson | January 15, 2005 at 02:04 PM

Doesn't using the feed URI as the channel/rdf:about rather change the meaning? You're no longer doing RDF Site Summary, you're doing RDF Self Statements.

Posted by: Phil Ringnalda | January 15, 2005 at 05:17 PM

Phil R: Not completely. First of all, the Items each have an rdf:about that is the item. So, it says "The URI /feed has a list of items: here they are." Then it attaches a title and description to /feed, saying this is "Danny's Entries". Nothing there is semantically inconsistent, although it is slightly less informative about the actual weblog, but that's not neccesarily always appropriate anyway.

Posted by: Christopher Schmidt | January 16, 2005 at 12:46 AM

I see by your FOAF (skating over some details of broken things) that http://crschmidt.net/blog is yours, so I query my triplestore for RSS items in a channel that's about that resource, and...

Are you going to make me look for a string literal /channel/link, to go from one bit of RDF to another? Or is RSS so much what you produce that your FOAF will just say you are the maker of the RSS, rather than the website?

In your case, yes, you write individual pages, and you are the FOAF maker of them all, and I could track them down that way, but that's still fairly rare. Most people are the maker of/have a weblog at one particular HTML page, that needs to be connected to the items that collectively make it up.

(Then, I'm eagerly awaiting the question of *which* proper mime-type, the unregisterable application/rss+xml or sending all application/rdf+xml to an RSS aggregator that only knows RSS 1.0's strictly limited RDF-XML.)

Posted by: Phil Ringnalda | January 16, 2005 at 01:37 AM

I thought I'd seen someone point it out, but the channel's rdf:about is an identifier, of which using the RSS's URL (or the channel's homepage) is only a suggestion for creating that identifier.

It's more likely that one would want to create a new property of the channel that references the feed, like

<channel rdf:about="http://example.org/news">
<admin:feed rdf:resource="http://example.org/news.rdf"/>

I don't think the question of "which" MIME type is all that important. This is an issue with all generic container formats (XML, RDF, property lists) or specific formats that are used like generic containers (RSS/Atom, OPML). When it becomes an issue, MIME handlers will be written to handle dispatching to another handler.

Posted by: Ken MacLeod | January 16, 2005 at 09:12 PM