This document describes a playlist format named "XSPF", which stands for "XML Shareable Playlist Format". "XSPF" can be pronounced "spiff" or maybe "spliff."
This is an informal document not associated with any standards body. It is intended to be clear and readable rather than conformant with existing standards for such documents.
This is the fourth draft of this document. It is a major rewrite, and there are a number of areas where the result is rough. This document assumes that your browser supports CSS reasonably well; versions of Internet Explorer older than version 6 don't. Items marked like [[fixme: this]] are markers for work yet to be done. See the todo list for more details about this document.
The home of our working group is http://xspf.org. On IRC, we use #playlist on irc.freenode.net. There are perhaps six regular contributors, with another six commenting from time to time. Contributors came from two major audio software vendors, a major weblog aggregator, the W3C, and two significant .org sites related to music. We worked in the skunkworks style and were not sponsored by any organization or standards body. Our purpose was to engineer a high-quality design rather than to create normative requirements for interoperability.
This document is maintained by Lucas Gonze.
Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.
The genesis of this project came from the mutual recognition that the quality of playlist formats fell far below the normal standard for hypertext document types like HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:
Over the course of our work we also realized that the format had to scale down well. The dominant playlist format is M3U, which is just a flat listing of song paths, and many developers are satisfied enough to stick with it. SMIL is all three of open, portable and well made, but is too complex for many needs; simple SMIL playlists are not simple to implement. Similarly, RDF offered well made solutions to many problems we faced, but RDF tools are never trivial (as of this writing). We went to great lengths to make trivial playlists trivial to implement.
The most pressing question for software developers is why should I support this XML playlist format instead of or in addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why does the world need yet another XML playlist format? The answer is XSPF is by far the most carefully crafted XML playlist format.
<?xml version="1.0" encoding="UTF-8"?> <playlist version="0" xmlns = "http://xspf.org/ns/0/"> <trackList> <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track> <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track> <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track> <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track> <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track> </trackList> </playlist>
An ordered list of URIs. The purpose is to satisfy licenses allowing modification but requiring attribution. If you modify such a playlist, move its //playlist/location element or //playlist/identifier to the top of the items in the //playlist/attribution element. xspf:playlist elements MAY contain exactly one xspf:attribution element.
<attribution> <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location> <location>http://bar.com/modified_version_of_original_playlist.xspf</location> <location>http://foo.com/original_playlist.xspf</location> </attribution>
The link element allows non-XSPF web resources to be included in XSPF documents without breaking XSPF validation.
<link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link>
URI of a resource.
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.
Ordered list of xspf:track elements to be rendered. xspf:track elements MUST be rendered in the order in which they appear, from top to bottom, unless a different ordering is otherwise indicated. If an xspf:track element cannot be rendered, a user-agent MUST skip to the next xspf:track element and MUST NOT interrupt the sequence.
The link element allows non-XSPF web resources to be included in xspf:track elements without breaking XSPF validation.
<link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link>
URI of a resource.
The meta element allows non-XSPF metadata to be included in xspf:track elements without breaking XSPF validation.
<meta rel="http://example.org/key">value</meta>
Value of the metadata element. MUST be valid text/plain, not XML.
See the XML Base specification or IETF RFC 2396:
The rules for determining the base URI can be summarized as follows (highest priority to lowest):
- The base URI is embedded in the document's content.
- The base URI is that of the encapsulating entity (message, document, or none).
- The base URI is the URI used to retrieve the entity.
- The base URI is defined by the context of the application.
On a surface level you can use XSPF like any other playlist format. Drop a bunch of filenames into an XSPF document, prepend "file://" to each, and you're ready to go. Under the surface there is much more.
The guiding design principle was to separate the functionality of a catalog of files from the functionality of a list of songs. Most MP3 players have some sort of cache for file information. This cache stores a list, or catalog, of available files and metadata from ID3 tags and other sources. XSPF is not a catalog format. XSPF exists only to say which songs to play. Almost everything in XSPF is for the purpose of answering the question which resource, rather than the question what is this resource.
If XSPF is not a catalog format, what is it? XSPF is an intermediate format. We expected a new kind of software called a content resolver to do the job of converting XSPF to a plain old list of files or URLs. A content resolver would be smart enough to keep your playlists from breaking when you move your MP3s from /mp3s to /music/mp3. It would be able to figure out that a playlist entry by the artist "Hank Williams" with the title "Your Cheating Heart" could be satisfied by the file /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how to query the iTunes music store or another online provider to locate and download a missing song.
The content resolver maintains the catalog of your songs in whatever format it prefers. It might use a flatfile, a file in the Berkeley DB format, or a SQL database. It might use only ID3 metadata, but it might also know how to query MusicBrainz or another metadata service.