Andreas Haugstrup Pedersen | solitude.dk

Through Lucas Gonze I saw Tim Berners-Lee's Links and Law. Lucas pulls out this quote:

A normal hypertext link does NOT necessarily imply that

• One document endorses the other; or that
• One document is created by the same person as the other, or that
• One document is to be considered part of another.

This is important. I agree that normal links has no implied meaning or relation. Lucas uses this as argument as to why playlist creators should not be scolded for linking directly to media objects instead of the encapsulating. I think he leaves out the most important thing. In the very next section Berners-Lee writes:

Images, embedded objects, and background sounds and images are by default to be considered part of the document.

Embedded objects are a part of the document. This is also true for blog entries where links marked with rel="enclosure" carries with it meaning (links marked with the rel attribute have meaning, they are not regular links). They carry the meaning that the destination of the link is a part of the current document — just as if it had been an embedded object.

And people should respect that relationship and not link directly to the media object. Links should point to the blog entry permalink. By extension of the rule that normal links carry no meaning blogging engine must not add any media object linked as enclosures in a feed.

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>

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.

…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.

Dave Winer posted an entry on how blogging tools should support enclosures. He is still missing the most important part.

I've seen other approaches discussed, for example, scraping the HTML of the blog post, looking for a link to something enclosure-like, and generating the enclosure element from that. This approach has problems, for example, how does the user control which element is enclosed? There can be more than one anchor element in the HTML text.

This is exactly what the rel-attribute was created to handle! It describes relationships between resources — such as, oh, I don't know, between the permalink and a Podcast mp3. You can't create an RSS feed containing enclosures without having the same information saved in the permalink. What happens when someone (like a computer program) goes to the permalink one month later? That's right, it can't find the enclosure if it's not described in the HTML. RSS is a syndication format. It syndicates information saved elsewhere, syndicating enclosures without having appropriate mark-up is just plain wrong.

Update

I've updated my thoughts on enclosures by writing a HTML Meta Profile For Blogs. There are two related blog entries:

• Meta Profile For Blogs
• Why Guessing Is Bad

For a couple of minutes this entry was called “Wordpress Sucks”. That's not fair, so I decided to change the title. Wordpress is the most interesting blogging system out there right now. That's where the innovation is happening. I just don't think what they've done here is a good idea.

I really like Wordpress, but when I read how Wordpress is handling enclosures I was disappointed. Wordpress looks for any links to an mp3 file in each entry and adds those to the RSS feed as enclosures. That's not a good way to do things. What happens when I link to someone else's Podcast? Their Podcast will be added to my feed as a part of my blog entry. That's one broken feed.

RSS is a syndication format. It represents content which exists elsewhere. Thus any changes must happen on the HTML-level and not in the feed. The feed must not contain any content that the HTML is represents does not contain. That's why you break RSS when you mindless add enclosures that may or may not be a part of the blog entry.

In addition you would have to wait for updates in your blogging system every time you wanted to include a new type of file. Right now Wordpress looks for mp3 files, but what about Quicktime video files, Windows Media audio. What about photoblogs who might want to add their photos as enclosures? Hell, what about Excel spreadsheets? We need a general way of describing links, not a patch solution like the one Wordpress has made.

I propose that blogging systems and websites start using the following HTML notations to help determine whether the content behind a link is to be seen as an integral part of a HTML document or not. I'm using <a>-elements below, but the same applies to <link>-elements. Examples are at the bottom of this entry.

<a href="[URL]">Link</a>

This is a normal link describing a reference to the linked resource. The URL the link points to should not be added as an enclosure since links by definition point to another resource.

<a href="[URL]" rel="alternate">Link</a>

The rel="alternate" is a part of the HTML specification:

Alternate. Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).

This type of link (along with a type attribute) designates that the content of URL pointed to can be substituted for the content of the HTML document. Ie. the URL can be understood without the context of the HTML document where the link resides. The URL linked should be added to the RSS feed as an enclosure.

<a href="[URL]" rel="enclosure">Link</a>

This is a new type of relation. It designates that the URL pointed to should be seen as a part of the HTML document, but not as a substitute for the HTML document. It compliments it rather than substitutes it. The linked URL should be added to the RSS feed as an enclosure Hints about content-type can be given with the type attribute).

Of course changes to the UI of blogging systems must be made. It is only the author of a given document who can make the distinction between the three different links. There is no way software can make the correct guess. The blogging system should provide some way for the author of an entry to mark links as belonging to one of these three categories. When creating links while authoring an entry it would be ideal if the blogging system at the same time as embedding the HTML code gave the author a choice as to what kind of link he is making.

If you want to use a profile attribute to show that you are using the enclosure as described here it should point to http://www.solitude.dk/archives/20041026-1300/

Examples

The following three paragraphs should be seen as examples of (short) blog posts. They have been created as to show the difference between the three different kinds of links.

<p>I was listening to Dave's <a href="http://static.scripting.com/blogs/gems/davetravel/cnOct24a.mp3">new Podcast</a> the other day. He has some good points in it.</p>

<p><a rel="alternate" href="http://www.solitude.dk/archives/files/podcast.mp3">My lastest video.</a> A short tour of my university campus.</p>

<p>I've been working on a new design for this website. I'm having some issues getting it to look right in Browser X. <a rel="enclosure" href="http://www.solitude.dk/archives/files/screenshot.png">Here is how it looks in Browser X</a>. Any help would be much appreciated.</p>