Integrating rich media seamlessly into weblog

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/>
Commentary on media, communication, culture and technology.