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.
<?xml version="1.0" encoding="UTF-8"?> <playlist version="0" xmlns = "http://xspf.org/ns/0/"> <trackList> <track><location>file:///mp3s/Yo+La+Tengo/And+Then+Nothing+Turned+Itself+Inside-Out</location></track> <track><location>file:///mp3s/Yo+La+Tengo/Genius+%2B+Love+%3D+Yo+La+Tengo+%28Disc+2%29</location></track> <track><location>file:///mp3s/Yo+La+Tengo/I+Can+Hear+The+Heart+Beating+As+One</location></track> <track><location>file:///mp3s/Yo+La+Tengo/Nuclear+War</location></track> <track><location>file:///mp3s/Yo+La+Tengo/Summer+Sun</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.