The OpenMedia project entails playlists with unique requirements. This document describes a way to use the XSPF shareable playlist format to meet those requirements.
Caveat: the OpenMedia web site is still private, though access is available to anyone who asks, so there is a touch of snobbery in my writing here.
OpenMedia is about audio or video objects on the web. These audio/visual objects are registered in a central database, from which they get an identifier.
Audio/visual objects are not commonly identified with a URL of a web-accessible resource. Rather, they are accessed via a URI containing the registry number, then converted by a lookup service into any of a variety of URLs depending on context. For example the item with ID 123 might be identified as openmedia:123; that identifier might be passed to a lookup service using a URL like http://openmedia.org/registry/123; and the lookup service might then return either a redirect to a resource or a document containing a list of alternate URLs.
In the jargon of the XSPF project, an OpenMedia registry number is a canonical ID, meaning an identifier which resolves to only one media object but which is not an address.
The method for expressing a canonical ID in XSPF uses the id element within a track listing. The following is XSPF expressing a collection of OpenMedia objects with identifiers 123, 456, and 789:
<?xml version="1.0" encoding="UTF-8"?> <playlist version="0" xmlns = "http://xspf.org/ns/0/"> <trackList> <track><id>openmedia:123</id></track> <track><id>openmedia:456</id></track> <track><id>openmedia:789</id></track> </trackList> </playlist>
But what if there is no lookup service, or if the author of a playlist prefers to give the URLs for any resource that matches his canonical identifiers without going through the lookup service? He might want multiple URLs because he had several different versions of the resource, like an MP3 version, an Ogg Vorbis version, and a Windows Media version. In this case he would give the URL for each of the alternatives within the track element and allow the client to choose among them, like this:
<?xml version="1.0" encoding="UTF-8"?> <playlist version="0" xmlns = "http://xspf.org/ns/0/"> <trackList> <track> <location>http://example.org/123.mp3</location> <location>http://example.org/123.ogg</location> <location>http://example.org/123.wma</location> </track> <track> <location>http://example.org/456.mp3</location> <location>http://example.org/456.ogg</location> <location>http://example.org/456.wma</location> </track> <track> <location>http://example.org/789.mp3</location> <location>http://example.org/789.ogg</location> <location>http://example.org/789.wma</location> </track> </trackList> </playlist>
The issue of metadata for media objects brings up a requirement specific to the OpenMedia project -- openness. OpenMedia is not intended to definine metadata formats, nor is it intended to pick winners among the many competing metadata formats, nor is it intended to fence users into a specific metadata format. How can it provide support for high quality metadata without breaking with these requirements?
XSPF addressed this problem with a standard wrapper for externally-defined metadata. This wrapper allows us to validate most metadata, hence guarantee syntactic correctness, regardless of the source of the data or the source of the metadata specification, and this allows us to provide both quality and openness. The wrapper is the meta element, which is defined as follows:
The meta element allows non-XSPF metadata to be included in XSPF documents without breaking XSPF validation.
<meta rel="http://example.org/key">value</meta>
Value of the metadata element. MUST be valid text/plain, not XML.
Putting this into practice, let's say there is a metadata format defined at http://foo/, and this format defines a property "artist" for the name of a musician associated with an audio/visual object. There is also a playlist referencing the OpenMedia a/v objects with IDs 123, 456, and 789. Lastly, we know the name of a musician associated with each of the media objects courtesy of the OpenMedia registry. An XSPF playlist containing this data would look like the following:
<?xml version="1.0" encoding="UTF-8"?> <playlist version="0" xmlns = "http://xspf.org/ns/0/"> <trackList> <track> <id>openmedia:123</id> <meta rel="http://foo/artist">Alice the guitarist</meta> </track> <track> <id>openmedia:456</id> <meta rel="http://foo/artist">Bob the viola wiz</meta> </track> <track> <id>openmedia:789</id> <meta rel="http://foo/artist">Carol the floutist</meta> </track> </trackList> </playlist>
Lucas Gonze