Home > All Posts > Individual Post
Post #1546

Integrating rich media seamlessly into weblog

By Andreas Haugstrup | "Andreas Haugstrup" <videoblog@...> | andreashaugstrup
October 28, 2004 | Post #1546 | Topic #1546

This is my attempt to start a new thread. We are moving into a broader perspective than just feeds though. For videoblogging to succeed in the same way I see three three different types of files (when I say 'document' I don't mean text. A document can also be audio, video, spreadsheet, whatever): 1) The permalink. This is the permanent location of the blog entry. It's a unique URL. It's also what's linked to in any syndication. The permalink needs to be as accessible and broad as possible. The best option in my opinion is to use HTML: - A huge amount of clients understand it. - It's easy to parse (even easier with XHTML). - It has a well defined vocabulary. - Already has mechanism in place for describing inter-document relationships (like alternate versions of the same document, or enclosures or appendixes etc.) In the future I foresee that blogging systems will be able to assign permalink directly to a media file (about the same time as a common format for media files come into mainstream use). For now blogging systems only support permalinks as HTML, and thus the HTML *must* be done right. So regardless we need to describe any inter-document relations not defined in the HTML spec. already (I can't see anyone except rel="enclosure" which I've already tried to define). And of course blogging systems need to use these inter-document relationships! It may sound trivial, but without this everything else falls apart. It's no use to have a great media file, if your permalink can't be parsed in a reliable way to find that media file! 2) The media file. Since we can't assign a permalink to the media file this gets it's own category. *All* metadata *must* be included in this file. This is imperative since you can't syndicate information you haven't saved somewhere (syndication is an act of copying information saved elsewhere). The format could be quicktime, real, windows media or any of the other five billion video formats. The problem with those is that it's hard to extract metadata from all these file formats (unlike MP3 where it's relatively easy to extract ID3 tags). The format could also be SMIL or CMML. Those are good because it's very easy to extract metadata. CMML sucks because no normal player can play the file. SMIL is better, but player support is still not great (for a SMIL file to play in Quicktime you actually have to break the SMIL file first). 3) The syndication file. This file handles syndication. It must not contain information not already in the media file and the permalink. Syndication must not add more information. The format could be Atom or RSS+enclosures. The syndication format needs to be very broad. It must be able to handle all kinds of permalinks and all kinds of enclosures (enclosures can be audio, video, HTML-document, a spreadsheet. Even a piece of software. Probably not a good idea to accept since it could be a fast way to distribute virus. The syndication should not be limited in the types of files it's able to syndicate. That's why Atom or RSS would solve the syndication issue just fine. If the client wants more information than provided in the feed it should fetch the information from the permalink and the media file. - Andreas -- <URL:http://www.solitude.dk/&gt; Commentary on media, communication, culture and technology.