Andreas Haugstrup Pedersen | solitude.dk

Microsoft are bouncing around drafts for new RSS icons. Scoble makes a note of why Microsoft likes icons over text:

We use icons to denote everything. Why not just text? Cause icons work better and we want to localize everything. Windows is available in 26 or so languages and icons translate better than letters like RSS or XML.

I agree completely. This is the exact same reason I generally prefer the iconic road signs you find in Europe over the symbolic US counterparts (there are exeptions). Maybe the Federal Transit Administration should listen to Microsoft — or better yet, hire me. Icons, baby, icons.

Through the power of Media RSS the webbased videoblog RSS reader mefeedia now provides thumbnails in its feeds. Check out the feed of recent videos. This is very cool. Generating automatic thumbnails is no tassk for the average user, and this addition makes mefeedia just that little bit snazzier than everyone else on the block.

Today the final version of the Yahoo Media RSS specification was released. I have been anticipating this for a while, since this module adds very important additions to straight-up RSS. Most importantly:

• You can now have more than one enclosed file per blog entry.
• You can provide each enclosure in several formats.

And my name is in the Acknowledgements — how cool is that?

Media RSS should now be implemented in this blog's feeds (both standard and full text feed). Just to test I have attached a photo of some flowers, and a video of a squirrel crossing the street. Both recorded in Ann Arbor the other day.

Nb. Comments on this should probably be directed to the audvidsyn Yahoo group mediarss Yahoo group. Track/pingbacks from the blogosphere are of course encouraged.

There has been some discussion on multiple enclosures in RSS. Dave Winer has clarified that RSS 2.0 only supports one enclsoure per item, something that in my opinion makes RSS 2.0 unfit for blog entries. The talk on multiple enclosures has been very focused on audio and video media, and that's being too narrow. The discussion needs to be opened up, enclosures are much much more than putting talkshows on your iPod.

The current enclosure element in RSS 2.0 is good because it makes no assumption on what kind of file it's linking to. This is a limit regarding including media specific metadata, but what you lose in that department you more than make up for in versatility. Below it'll describe my proposal for an enclosure extension to RSS 2.0. Below I'll describe the proposal, and give a handful of examples of possible uses (just to show how cool and easy this is). Comments are of course very welcome — implementations moreso!

RSS 2.0 Extension: Enclosures (draft)

This is an extension to RSS 2.0 in response to the lack of support for multiple enclosures in the original RSS 2.0 specification. The goal is to incorporate the following into RSS:

• Support for multiple enclosures.
• Support for multiple versions of each enclosure.

Namespace declaration

xmlns="http://www.solitude.dk/syndication/enclosures/"

The enclosure element and children

The containing element an enclosure is enclosure and it goes inside the item in the feed. Each item may contain any number of enclosure elements. Each enclosure represents an “enclosure” — either a single file attached to the item or several files that should be regarded as multiple versions of the same content attached to the item.

The enclosure element can have one optional attribute (title, as defined below), and can contain any number of link elements. Each link represents an actual file. Thus an item with one enclosure which only exist in one version would be represented by one enclosure element with one link element as a child. The link element has three required attributes, and one optional:

url

The location of the file.

type

The content type of the file (standard MIME type).

length

The size of the file given in bytes.

title (optional)

Additional information about the file, or the enclosure as a whole in the case of the enclosure element.

An example of an enclosure, available in one version will look like this:

<enclosure title="An image" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="200" url="http://www.domain.com/image.jpg" /> </enclosure>

Distinguishing versions

It makes no sense to have multiple versions of the recipient has no way of making a choice as to what version is most appropriate. Each of the attributes (apart from the url) gives you an opportunity for choice.

By looking at the type you will be able to find the type of media/content that best suits your situation. This can be as simple as setting up your aggregator to prefer Quicktime over Windows Media videos, but it can also be used to choose between a spreadsheet from Excel and a SVG graph representing the same numbers. The length could be used to determine quality within the same type. Eg. if two files within the same enclosure has identical type attributes, the file with the longer length could designate the file of the highest quality.

As a last resort the title can be used to determine which version is the most appropriate. The drawback of course being that it is not possible for machines to do much automatic sorting based on the title (since the value is arbitrary). Humans will be able to make choices based on the title just fine though.

Examples

I have created some examples to demonstrate the versatility of this simple approach to enclosures. I'll go through the examples below, but if you prefer I have also collected them in an RSS file.

Simple photoblog entry

This is a simple photoblog entry. It contains a single photo as the enclosure. It requires more markup than the standard RSS enclosure, but that's the price to pay for the added possibilities.

<enclosure title="My pretty photo" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="52200" url="http://www.domain.com/photo.jpg" /> </enclosure>

A call for help!

Some times I mess up, and a part of every good call for help is additional information. In this case the problem is described in the standard description element, and attached are two files: An error log (a text file) and a screenshot of the problem.

<enclosure title="Error log" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="text/plain" length="100" url="http://www.domain.com/error.txt" /> </enclosure> <enclosure title="Screenshot of the error" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/png" length="100" url="http://www.domain.com/screenshot.png" /> </enclosure>

This is Rocketboom

Rocketboom is a videoblog. They post one video per day, but this video is available in three versions (Quicktime, Windows Media and BitTorrent).

<enclosure title="Rocketboom: Casual Friday" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="video/quicktime" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov" /> <link type="video/x-ms-wmv" length="100" url="http://www.rocketboom.com/video/rb_05_feb_04.wmv" /> <link type="application/x-bittorrent" length="100" url="http://www.rocketboom.com/rb_05_feb_04.mov.torrent" /> </enclosure>

More advanced photoblog

In some cases it might be nice to distribute thumbnails along with the full sized images in a photoblog. This is a representation of a photoblog entry containing three photos (a series). A thumbnail of each photo is included.

<enclosure title="Photo in a series" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="52200" url="http://www.domain.com/photo1.jpg" /> <link type="image/jpg" length="1100" url="http://www.domain.com/photo1_small.jpg" title="Thumbnail" /> </enclosure> <enclosure title="Another photo" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" /> <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" /> </enclosure> <enclosure title="Ane one more photo" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="52200" url="http://www.domain.com/photo2.jpg" /> <link type="image/jpg" length="1100" url="http://www.domain.com/photo2_small.jpg" title="Thumbnail" /> </enclosure>

The Press release

If we look away from blogs, and back to the roots of RSS (newspaper syndication) the connection to using RSS to send out press releases is easy to make. It certainly makes for an easy way for a company to make things easier for the media who would like to reuse parts of the press release. The text of the press release goes in the usual description element, enclosed here are three items. A set of numbers telling how much money the company made, some headshots of a company bigwig, and the company logo. The last numbers (in the shape of a graph), and the logo are supplied both in versions for online use (PNG images) and for print (EPS files).

<enclosure title="Important company numbers" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="application/x-excel" length="100" url="http://www.company.com/spreadsheet.xls" /> <link type="image/png" length="100" url="http://www.company.com/spreadsheet-graph.png" /> <link type="image/eps" length="100" url="http://www.company.com/spreadsheet-illustration.eps" /> </enclosure> <enclosure title="Headshots of company bigwig" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/jpg" length="100" url="http://www.company.com/headshot1.jpg" /> <link type="image/jpg" length="100" url="http://www.company.com/headshot2.jpg" /> <link type="image/jpg" length="100" url="http://www.company.com/headshot3.jpg" /> </enclosure> <enclosure title="Company logo" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="image/png" length="100" url="http://www.company.com/logo.png" /> <link type="image/eps" length="100" url="http://www.company.com/logo.eps" /> </enclosure>

Software Update

With enclosures it's possible to use RSS to do software updates by having the software pull down the RSS feed. With multiple enclosures, and multiple versions this becomes easier to manage. Here two files are distributed for a fictive anti-virus program. First a patch is available in two versions depending on the user's current version, and then a virus definition update is included (common for all versions of the anti-virus program).

<enclosure title="Software patch" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="application/octet-stream" length="100" url="http://www.domain.com/patch.exe" title="Patch for software versions less than 2.0" /> <link type="application/octet-stream" length="100" url="http://www.domain.com/patch_20.exe" title="Patch for software versions above 2.0" /> </enclosure> <enclosure title="Virus definitions" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="text/plain" length="100" url="http://www.domain.com/definitions.txt" /> </enclosure>

The daily playlist

Webjay is an online playlist community where users share media. With multiple enclosures it would be possible to aggregate the most shared tracks in multiple playlist formats. Below a single playlist is enclosed in three different versions.

<enclosure title="Webjay.org's daily playlist" xmlns="http://www.solitude.dk/syndication/enclosures/"> <link type="audio/x-mpegurl" length="100" url="http://www.domain.com/playlist.m3u" /> <link type="application/xspf+xml" length="100" url="http://www.domain.com/playlist.xml" /> <link type="application/smil" length="100" url="http://www.domain.com/playlist.smil" /> </enclosure>

Lately all the rage has been about the hot new thing for videobloggers. Jay has hyped it, and there is more coverage by Adrian and Steve. ANT is a specialised video feed reader for the Mac. It will read feeds and play any video marked as enclosures. Actually it will play anything that Quicktime can play, so it will play a wide range of audio files as well. I've been following a bit on the sideline, and the amount of work that has gone into the program is pretty amazing. In the same line of software there is Mefeedia (formerly Me-Tv) — a web-based specialised video feed reader.

I don't use either of these feed readers, I have an account at Mefeedia to see what Peter is doing with it, but that's it. I don't expect to begin using them in the future for the simple reason that I don't subscribe to video, I subscribe to people.

The underlying assumption with both ANT and Mefeedia is that video is more important than other types of content. That's the whole concept of an aggregator that only reads one type of media after all. It's a little bit pretentious, but I'll let that slide. The point is that when I click ‘Subscribe’ on Lisa's weblog for example I don't do it because there is video, I do it because Lisa has good content. As a reader/viewer/whatever I'm interested in what she has to say, not how she says it. That's why these specialised readers will not work for me.

They still serve a purpose in my world. With a bit of luck applications like ANT and Mefeedia will open the eyes of the people who produce regular feed readers to think about enclosures, and how to support them. I need to have everything in the same feed reader. I don't want to have to check Lisa's blog in three places (one for text, audio and video). I want Lisa to be one accesspoint in my feed reader, because it's Lisa I'm interested in (not in that way, perverts). As a small example Eric Rice did a short demonstration of how to get audio entries to show up in ANT. It was very nice, now ANT just need to start supporting text. Where would Lisa's blog entries fit in anyway? I picked her as my example because she mixes media freely on her blog.

My demands aren't many. It would be easy to get a rudementary support for “rich” media in my favourite feed reader. A simple note that audio or video content (or any other kind of enclosure, really) is available would go a long way. The reader doesn't need to download these enclosures in the background, in fact I would prefer if it didn't. I will screen the audio/video content by the text description anyway — an automatic download would just waste bandwidth. Using Quicktime's Fast Start so the whole file doesn't have to download before starting playback gets rid of the waiting problem, and blog entries are short anyway.

All I'm asking for is a little icon and title or file name. I can then click to view the audio/video. The feed reader wouldn't support playback within the feed reader — it should hand off a pointer to the operating system so my default player will handle playback. That way the feed reader will handle all types of files out of the box.

I've made small adjustments to the RSS feed I offer. The default feed now contains only an excerpt, but it also contains a note explaining which (if any) enclosures the entry contains. These are not added as real enclosures because RSS 2.0 only allows for one enclosure per entry, and I routinely have more than one. I'd rather not offer any than only offer a subset.

The old feed with full text is now located at http://www.solitude.dk/rss/?type=full. It should function exactly as before, with all the trouble that encompass like images not showing up in the feed reader.

Dave Winer has clarified an important part of the RSS 2.0 specification (via the audvidsyn list):

[…] Anyone who really read the spec would come to the conclusion that RSS allows zero or one enclosures per item, and no more. […] The spec refers to “the enclosure” in the singular. Regardless, some people persist in thinking that you may have more than one enclosure per item.

Following that I decided to abandon my plans of adding enclosures to my own feed for the simple reason that without multiple enclosures I can't make the feed represent the content of the blog entry. I often attach more than one photo to a blog entry, or I attach a stillshot from a video along with the video itself.

Limiting blog entries to just one enclosure sounds awfully backwards andvery limiting to how blog posts can be written. It's certainly not the kind of freedom bloggers are used to. I would take it so far as to claim that it's useless for blogging (but perhaps Winer only thinks that podcasters have use for enclosures).

I honestly don't get the problem with allowing multiple enclosures. Just allow more than one instance of the <enclosure>-element, and the problem is solved.

I've written before on why guessing when including files as enclosures is bad, but I would like elaborate a bit. To paraphrase my previous entry guessing is bad because the wrong files will be tagged as enclosures which results in muddy data (and likely confusion). In addition having only the enclosures marked in the RSS feed ensures that it's only possible to extract the enclosures while the blog entries are present in the feed — thus you will loose this very important information after the entry is pushed off the end of the feed.

What annoys me the most is that the current practice of guessing limits me in what I can and cannot link to. I can't link directly to media files because Me-Tv and services like it will display the media file as the primary content, even if I only linked to the file in a side comment. For example I can't write:

Peter, Kenyatta, Josh, Jay and Mica were <a href="http://poorbuthappy.com/ease/video/metv.mov">hanging out</a>. It looked like they had a lot of fun talking about Me-Tv.

Likewise Feedster will add the media file as an enclosure and assume that I am the owner of said media file. Following that line of thought the guessing actually limits how audio/video and weblogs can interact instead of opening up new possibilities — audio/video is marked as something seperate from the weblog, not as a part of it.

That was my primary goal with writing the HTML Meta Profile For Blogs. It gives authors a way of tagging files that should be considered enclosures. The advatanges are multiple.

1. The information about which files are enclosures are saved permanently with the blog entry, not only temporarily in the feed.
2. There is no muddy data since only the files the author has marked as enclosures will be treated as such.
3. As a result you can link to any kind of file without having to worry about it being presented as the main content of your blog post.

Of course changes would still be needed in the user interface of blogging systems to make it easy for non-HTML savvy authors to mark files as enclosures.

In the popular “Phenomenon X Sucks” series I present: My Feed Reader Isn't What It Should Be. I like the concept of newsfeeds — that I am automatically notified when a website (or more likely weblog) is updated. The interface and integration with my browser is kind of clunky though. This is funny since the feed reader is actually integrated into the browser I use.

The reader is a part of the e-mail client, which I have been content with until I got thinking tonight. Whenever a new item is picked up by the feed reader it is archived in a folder with the rest of the items from that website. This sucks because when Vlog 2.1 is updated I have a lot of scrolling to do. I used to think that newsfeeds fitted best into the e-mail paradigm (opposed to the bookmark paradigm Firefox has gone with). But really a combination of both would be the optimal for me.

What I would like is a sidebar in my browser — and it should be a part of my browser and not a stand-alone program — like the one in this entry (I have just added some random items from my feed reader). I already have sidebars for e-mail, bookmarks, recent downloads, chat and a handful other things by default, so how hard can it be to add one for newsfeeds?

This sidebar would be a constant flow of the most recently recieved items, let's say the last 50 because I'm not going to be watching the list constantly. It would be my own personal, customizable window into the blogosphere (or the blue-cow-sphere as we say in Danish). The sidebar would simply show the title and the excerpt of each item with a link to visit to full story/blog post/video entry. There should be a small note saying which website the item is from too.

I would still have my regular feed archives because they're nice for searching, but I would prefer to use this blogosphere-window as my main feed reader. The concept of only showing new items in the archived folder for the website is stupid, because it is by default it is irrelevant which feed the item came from — I added the feed to the reader so I'm interested in all entries. Of course some people use feeds differently and have their feed reader collect items from a huge list of websites. This would be handled by being able to mark some feeds as favourites, and only favourites would show up in The Window of the Blue Cow.

And the icons next to the items? The reader supports enclosures so it can tell me what kind of content I'll be looking at (images, video, audio, porn). More on that later.

…and the Max Power way. As Homer Simpson beautifully put it:

Homer:

There are three ways to do things: the right way, the wrong way, and the Max Power way!

Bart:

Isn't that just the wrong way?

Homer:

Yeah, but faster!

Eric Rice notices that his syndication traffic has surpassed his normal traffic and notes:

Right now, Steve Gillmor is reading this and smirking at me. He believes the HTML page model is, or will be, dead. I'm not totally opposed to all aspects of that idea, however it seems to me that to get the same user experience to show up in RSS feeds, feed programs need to become browser v.2.... so are we just rebuillding the web?

And he is right. Not only would you be reinventing HTML, you would be doing it worse than Max Power. It would be the wrong way, but slower. And let me tell you this: Solving a problem worse than Homer Simpson is a pretty awful way of solving an idea.

No matter how deep into the RSS can do friggin' anything camp you are, you have to admit that HTML handles hypertext a truckload better than RSS will ever do. That's because HTML was designed to handle hypertext and RSS was designed to handle syndication of said hypertext. HTML has had over 10 years to develope a markup language to handle hypertext, RSS has spent exactly zero seconds trying to solve the issue of handling hypertext (it handles syndication pretty well though).

For RSS to replace HTML it would need to become HTML, with added syndication features. That's solving the problem the wrong way slowly (why the hell would you ever want to reinvent HTML from scratch like that). It's making a relatively simple problem very complex — just like American voting machines.

I already have a seamless integration between the syndication (RSS) and content (HTML) working quite nicely. RSS is integrated into my webrowser so I don't notice when I switch from RSS to HTML and back. If the problem is that you want the content show up in it's glory look at the permalink and load the damn page automatically.

With that said there's one more simple reason that RSS can't replace HTML. You can't archive RSS very well (or at all). How do you link to an item in a feed? Oh, right — you can't. How's that for killing conversations on the web. Even if you could link to an item the item would disappear once the item is pushed off the end of the feed.

Are you going to say that you'll just split the items into different files and save them where people can link to them? Maybe you'll also add the ability to link and quote. Congratulations, you just re-inveted HTML with different element names. You all can take your RSS-can-do-anything statements and shove them up your… Think before acting, people. What would be easier? Adding syndication features to HTML (like RSS is doing currently) or adding all of HTML to RSS? Yes, that's a rhetorical question.