A very simple document looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
  <trackList>
    <track><location>file:///music/song_1.ogg</location></track>
    <track><location>file:///music/song_2.flac</location></track>
    <track><location>file:///music/song_3.mp3</location></track>
  </trackList>
</playlist>

or this:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
  <trackList>
     <track><location>http://example.net/song_1.ogg</location></track>
     <track><location>http://example.net/song_2.flac</location></track>
     <track><location>http://example.com/song_3.mp3</location></track>
   </trackList>
 </playlist>

Our group started work in February 2004, achieved rough consensus on version 0 in April 2004, did implementations and fine tuning throughout summer and fall 2004, and declared the tuned version to be version 1 in January 2005. Between August and November of 2006 we unfroze this document for a final round of improvements to the drafting, limiting changes to those which did not require any implementation to be modified.

Ian C. Rogers and Robert Kaye bootstrapped our project. Dave Brown, Dan Brickley, and Kevin Marks contributed ideas which had a strong influence on architecture and syntax. Sebastian Pipping and Ivo Emanuel Gonçalves were the drivers behind the 2006 revisions.

We are grateful for comments and feedback from Ryan Shaw, Alf Eaton, Steve Gedikian, Russell Garrett, Ben Tesch and Pau Garcia i Quiles. Special thanks to the developers Tomas Franzén (who participated in our work from the very beginning), Jim Garrison, Brander Lien, and Fabricio Zuardi, and to everyone who contributed their time and skill on the mailing list and wiki.

We would especially like to thank our hosts at the the Xiph.org foundation and Metabrainz foundation for their continuing generosity.

2.3.1 URI, URLs and URNs

2.3.2 Requirements notation

An XSPF playlist describes a sequence of objects to be rendered. Objects might be audio, video, text, playlists, or any other media type. The function of a playlist is to identify the objects and communicate their order.

The function of a playlist is not to communicate metadata about the composer, song title, etc. Metadata is hard and there are many providers already. We decided that we couldn't compete, and that there was no need for us to try. Moreover, good metadata does not travel well — every user has to recreate it. Metadata should come from external sources and namespaces like MusicBrainz or Gracenote; this what the XSPF link and meta elements are for.

The function of a playlist is not to store derived information about objects that a user has a copy of. A playlist is not a catalog. A catalog is computed across hard data like files; it stores information like filesystem paths and the contents of ID3 tags. This data has no value on any machine but the one on which it originated. Sharing this data would be a privacy and security violation. Software which needs access to this data has no reason to maintain it in a standard format, because it has no reason to allow access to it. Standardizing this data would be fruitless, because there are an endless number of measurements that software might take and store. Derived information belongs in a catalog.

Things a playlist is not, then, are a metadata format or a catalog. We took care to enable these features, but also to avoid duplicating their functionality, poorly.

If there is no reason for a playlist to be shared, there is no need for a new format. Even a buggy format does no damage if it is created and consumed by the same software on the same machine. The need for a new format only comes up when a playlist travels from one machine to another, for example when it is published on the internet.

One type of shareability is between different pieces of software on the same machine. It is common for playlists created with one application to not be usable by another application on the same machine, because of different or conflicting interpretations of the playlist format. M3U suffers from this very badly, because M3U playlists often reference files according to a base path which changes from application to application. The XSPF group aimed to fix this by providing unambiguous definitions.

The other type of shareability is between different machines. For playlists to be meaningful on different machines, they must be able to identify network resources. Audio and video objects are often abstractions like "movie X by director Y" rather than computer-friendly objects like "whatever file can be gotten from the URI http://foo/x/y". To handle this problem, we have provided support for media objects to be found via queries; XSPF identifiers are fuzzy names.

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 software music players on the PC 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 URIs. A content resolver would be smart enough to keep your playlists from breaking when you move your media from /oggs to /music/ogg. 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 /vorbis/hankwilliams/yourcheatingheart.ogg. 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.

All XSPF user agents are content resolvers, in that they have complete leeway to turn the contents of a track element into a specific set of bytes.

Any given track can be identified in a number of ways. We provided means for absolute identifiers like URIs, filesystem paths and secure hashes, but also for query-based identifiers — free text fields like artist and work title and numeric fields for song length, all of which together should be enough for a good content resolver to turn into files.

4.1.1 playlist

$main_date = date("Y-m-d\TH:i:s", $timestamp);
$tz = date("O", $timestamp);  
$tz = substr_replace ($tz, ':', 3, 0);

<attribution>
  <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
  <identifier>somescheme:original_playlist.xspf</identifier>
</attribution>

<link rel="http://foaf.example.org/namespace/version1">http://socialnetwork.example.org/foaf/mary.rdfs</link>

<meta rel="http://example.org/key">value</meta>

<playlist version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
  <extension application="http://example.com">
    <cl:clip start="25000" end="34500"/>
  </extension>
  <trackList />
</playlist>

<link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link>

<meta rel="http://example.org/key">value</meta>

<playlist version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
  <trackList>
    <track>
      <extension application="http://example.com">
        <cl:clip start="25000" end="34500"/>
      </extension>
    </track>
  </trackList>
</playlist>

If a media player is unable to render a track in the sequence, the player MUST NOT stop rendering the sequence and MUST attempt to continue at the next track. Players will frequently encounter resources that they cannot render — this is not a fatal error unless the player stops processing the playlist.

Relative paths MUST be resolved according to the XML Base specification or IETF RFC 2396:

The rules for determining the base URI can be 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.

<location>My%20Song.flac</location>

<location>My Song.flac</location>

Applications MUST assign unique URIs from their own namespace for each link, meta and extension element. New URIs SHOULD be assigned if syntax and/or semantics of a link, meta or extension element changes.