[xiph-commits] r9290 - websites/xspf.org
lgonze at motherfish-iii.xiph.org
lgonze at motherfish-iii.xiph.org
Tue May 17 15:40:55 PDT 2005
Author: lgonze
Date: 2005-05-17 15:40:53 -0700 (Tue, 17 May 2005)
New Revision: 9290
Added:
websites/xspf.org/xspf-v0.html
websites/xspf.org/xspf-v1.html
Log:
HTML flavors of the specs.
Added: websites/xspf.org/xspf-v0.html
===================================================================
--- websites/xspf.org/xspf-v0.html 2005-05-16 22:57:54 UTC (rev 9289)
+++ websites/xspf.org/xspf-v0.html 2005-05-17 22:40:53 UTC (rev 9290)
@@ -0,0 +1,910 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+blockquote {
+font-style: italic;
+}
+
+a {
+display: inline;
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+pre {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+pre:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+<a name="WhatisXSPF"/><h2>What is XSPF?</h2>
+
+ <p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+
+ <p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format are
+ proprietary. ASX resembles XML in that it uses angle brackets,
+ but is not XML by any means. M3U, RAM, and M4U are flat files;
+ QuickTime is binary; Pls is in the Windows .ini format;
+ Gnomoradio RDF is RDF, not XML. SMIL is too hard to implement.
+ The timing model of RSS doesn't fit audio and video. Forcing
+ timing models into HTML, as HTML+Time does, creates an
+ unintelligible feature set. Few of these formats are well
+ documented. None of these formats make simple features easy to
+ code and hard features possible. Only one is an open standard.
+ Not a single one offers interoperability across major vendors.
+ Not a single one attempts to solve these problems.</p>
+
+ <p>The pressing question for software developers is <em>why should
+ I support this XML playlist format</em> 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 <em>XSPF is by far the most carefully crafted XML
+ playlist format</em>.</p>
+
+<a name="Example"/><h2>Example</h2>
+ A very simple document looks like this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+or this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>http://yolatengo.com/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>http://yolatengo.com/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>http://yolatengo.com/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>http://yolatengo.com/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>http://yolatengo.com/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#WhatisXSPF">What is XSPF?</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Administrativenotes">Administrative notes</a></li>
+<li><a href="#Abstractions">Abstractions</a></li>
+<li ><ol>
+<li><a href="#Definingplaylists">Defining playlists</a></li>
+<li><a href="#Whataplaylistisnot">What a playlist is not</a></li>
+<li><a href="#Shareability">Shareability</a></li>
+</ol></li>
+<li><a href="#Elementdefinitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Designandarchitecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#Contentresolver">Content resolver</a></li>
+<li><a href="#Fuzzynames">Fuzzy names</a></li>
+</ol></li>
+<li><a href="#RequirementsforXSPFplayers">Requirements for XSPF players</a></li>
+<li ><ol>
+<li><a href="#Gracefulfailure">Graceful failure</a></li>
+<li><a href="#Relativepaths">Relative paths</a></li>
+</ol></li>
+<li><a href="#Usecasesforplaylists">Usecases for playlists</a></li>
+<li ><ol>
+<li><a href="#Flagplayerapplication">Flag player application</a></li>
+<li><a href="#Allowstreaming">Allow streaming</a></li>
+<li><a href="#Collectingfragmentedresources">Collecting fragmented resources</a></li>
+<li><a href="#Alternatemediatypes">Alternate media types</a></li>
+<li><a href="#Cachingderivedinfo">Caching derived info</a></li>
+<li><a href="#Metadatastorage">Metadata storage</a></li>
+<li><a href="#Authoringcompilationsforexpressivereasons">Authoring compilations for expressive reasons</a></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#HowtoIconvertXSPFtoM3U">How to I convert XSPF to M3U?</a></li>
+<li><a href="#HowtoIconvertXSPFtoHTML">How to I convert XSPF to HTML?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSMIL">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSoundblox">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#HowdoIcustomizeXSPFShouldIusenamespaces">How do I customize XSPF? Should I use namespaces?</a></li>
+<li><a href="#HowdoIvalidateXSPF">How do I validate XSPF?</a></li>
+<li><a href="#HowdoIuseMusicBrainzmetadata">How do I use MusicBrainz metadata?</a></li>
+<li><a href="#HowdoIrefertoaBitTorrent">How do I refer to a BitTorrent?</a></li>
+<li><a href="#HowdoIrefertoaMagnetorsha1URI">How do I refer to a Magnet or sha1: URI?</a></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+<a name="Administrativenotes"/><h2>Administrative notes</h2>
+
+ <p>Version 0 is frozen and complete. Anybody writing code
+ according to this specification can be very confident that it will
+ not change.</p>
+
+ <p>The home of our working group is <a
+ href="http://xspf.org">http://xspf.org</a>. Members include
+ Dave Brown and Ian Rogers of Yahoo; Dan Brickley from the W3C;
+ Kevin Marks of Technorati; Matthias Freidrich and Robert Kaye of
+ MusicBrainz; Ryan Shaw of UC Berkely; and myself, from Webjay.</p>
+
+ <p>This author of this document is <a
+ href="http://gonze.com">Lucas Gonze</a>. Our group started work
+ in the winter of 2004. The first public draft of this document
+ was May 9, 2004, the most recent was January 6, 2005.</p>
+
+ <p>In a few places in this document I will use the term MUST in
+ all caps, which will remind some readers of formal standards.
+ In this document the term should be interpreted to mean that
+ something shouted is important. XSPF is not a standard, it is
+ an ad-hoc project by a group of individuals.</p>
+
+<a name="Abstractions"/><h2>Abstractions</h2>
+
+ <dl>
+
+ <dt><a name="Definingplaylists"/>Defining playlists</dt><!-- first child of abstractions -->
+ <dd>
+ <p>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.</p>
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Whataplaylistisnot"/>What a playlist is not</dt><!-- first child of abstractions -->
+ <dd>
+ <p>The function of a playlist <em>is not</em> 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 <span class="elem">link</span>
+ and <span class="elem">meta</span> elements are
+ for.</p>
+
+ <p>The function of a playlist <em>is not</em> 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 <em>catalog</em>.</p>
+
+ <p>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.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Shareability"/>Shareability</dt><!-- first child of abstractions -->
+ <dd>
+
+ <p>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.</p>
+
+ <p>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.</p>
+
+ <p>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 URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ </dl><!-- end abstractions -->
+
+<a name="Elementdefinitions"/><h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URI of a resource that describes the license under
+ which this playlist was released. xspf:playlist
+ elements may contain zero or one license element.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>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.</p>
+ <pre>
+<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></pre>
+ </dd>
+
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more link elements.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more meta elements.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered.
+ The sequence is a hint, not a requirement; renderers
+ are advised to play tracks from top to bottom unless
+ there is an indication otherwise.<p/>
+
+ <p>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.</p>
+
+ <p>xspf:playlist elements MUST contain one and only
+ one trackList element.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</dd>
+
+ <dt><a name="duration"/>duration</dt>
+
+ <dd>The time to render a resource, in
+ milliseconds. It MUST be a valid <a
+ href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value is
+ only a hint -- different XSPF generators will
+ generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="Designandarchitecture"/><h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="Contentresolver"/>Content resolver</dt>
+
+ <dd>
+
+ <p>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.</p>
+
+ <p>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 <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> 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.</p>
+
+ <p>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.</p>
+ </dd>
+
+ <dt><a name="Fuzzynames"/>Fuzzy names</dt>
+ <dd>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, 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.
+ </dd>
+
+ </dl>
+
+<a name="RequirementsforXSPFplayers"/><h2>Requirements for XSPF players</h2>
+ <dl><!-- begin requirements -->
+ <dt><a name="Gracefulfailure"/>Graceful failure</dt><!-- first child of normative -->
+ <dd>
+ <p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+ <p></p>
+ </dd>
+
+ <dt><a name="Relativepaths"/>Relative paths</dt><!-- first child of normative -->
+ <dd>
+ <p>Relative paths MUST be resolved according to the <a
+ href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a
+ href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ </dl><!-- end requirements -->
+
+<a name="Usecasesforplaylists"/><h2>Usecases for playlists</h2>
+
+ <dl>
+
+ <dt><a name="Flagplayerapplication"/>Flag player application</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+
+ <p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+
+ <p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Allowstreaming"/>Allow streaming</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+
+ <p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+
+ <p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Collectingfragmentedresources"/>Collecting fragmented resources</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+
+ <p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+
+ <p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Alternatemediatypes"/>Alternate media types</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+
+ <p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URI within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+
+ <p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Cachingderivedinfo"/>Caching derived info</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+ <p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+ <p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Metadatastorage"/>Metadata storage</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+ <p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+ <p>XSPF' solution: XSPF defers this functionality to
+ other sources. Metadata is hard; there are already
+ many projects to deal with it, some of which are very
+ good. Metadata is attached to an XSPF track according
+ to whatever syntax an imported vocabulary defines.
+ XML namespaces may be used, but the preferred syntax
+ is the XSPF <span class="elem">link</span> and <span
+ class="elem">meta</span> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Authoringcompilationsforexpressivereasons"/>Authoring compilations for expressive reasons</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+
+ <p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URIs, into a file in the
+ M3U format.</p>
+
+ <p>XSPF' solution: The XSPF <span
+ class="elem">trackList</span> element contains a
+ sequence of <span class="elem">track</span> elements,
+ each of which points to one of the objects.</p>
+ </dd><!-- first child of usecases -->
+
+ </dl><!-- end usecases -->
+
+<a name="Recipes"/><h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ <dt><a name="HowtoIconvertXSPFtoM3U"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoHTML"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSMIL"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSoundblox"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</dd>
+ <dt><a name="HowdoIcustomizeXSPFShouldIusenamespaces"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ <dt><a name="HowdoIvalidateXSPF"/>How do I validate XSPF?</dt>
+ <dd><p>Robert Kaye has created a Relax NG schema for XSPF draft 8 at <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">http://mayhem-chaos.net/stuff/xspf-draft8.rng</a>. You can use <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a> to invoke it.</p>
+ <p>For users of Emacs nxml-mode, Ryan Shaw has posted a .rnc
+ version of Robert's schema at <a
+ href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html">http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html</a>.
+ This is just a matter of putting the .rnc file in the schema/
+ subdirectory of your nxml-mode installation. nxml-mode will
+ find it automatically and add it to the list of available
+ schemas; if you begin authoring an XSPF playlist, nxml-mode
+ will choose the correct schema by examining the root element
+ name.</p>
+ </dd>
+
+ <dt><a name="HowdoIuseMusicBrainzmetadata"/>How do I use MusicBrainz metadata?</dt>
+ <dd>
+ Rather than include the literal artist name, song duration, etc, for a track within a playlist, MusicBrainz gives the URL of an XML file containing these items. Assume that the MusicBrainz definition of what a track listing means is at http://musicbrainz.org/track. (There is nothing at that URL, which is fine -- the URL in an XSPF meta[@rel] attribute works the same way as the URL in an XML namespace declaration). A typical track listing has a URL like http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429.
+ <div class="example">
+<track>
+ <identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+ <title>Smoke Two Joints</title>
+ <creator>Sublime</creator>
+ <duration>175466</duration>
+ <meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+ </div>
+
+ </dd>
+
+ <dt><a name="HowdoIrefertoaBitTorrent"/>How do I refer to a BitTorrent?</dt>
+ <dd>Put the torrent file in a playlist/trackList/track/location element.</dd>
+
+ <dt><a name="HowdoIrefertoaMagnetorsha1URI"/>How do I refer to a Magnet or sha1: URI?</dt>
+ <dd>A sha1: URI is a location independent canonical ID, so it
+ belongs in a playlist/trackList/track/identifier element. A
+ Magnet URI is resolvable, so belongs in
+ playlist/trackList/track/location.</dd>
+
+ </dl>
+
+<a name="Administrative"/><h2>Administrative</h2>
+
+ <dl>
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-8.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-8.html">CSS</a></li>
+ </ol>
+ </dd>
+ </dl>
+
+ </body>
+</html>
Added: websites/xspf.org/xspf-v1.html
===================================================================
--- websites/xspf.org/xspf-v1.html 2005-05-16 22:57:54 UTC (rev 9289)
+++ websites/xspf.org/xspf-v1.html 2005-05-17 22:40:53 UTC (rev 9290)
@@ -0,0 +1,2156 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
+<html lang="en-US">
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<title>XSPF Version 1</title>
+<style type="text/css">
+a
+{
+ text-decoration: none
+}
+a:hover
+{
+ text-decoration: underline
+}
+a:active
+{
+ text-decoration: underline
+}
+body
+{
+
+ color: #000000;
+ font-family: helvetica, arial, sans-serif;
+ font-size: 13px;
+}
+dl
+{
+ margin-left: 2em;
+}
+h1
+{
+ color: #333333;
+ font-size: 16px;
+ line-height: 16px;
+ font-family: helvetica, arial, sans-serif;
+ page-break-after: avoid;
+}
+h2
+{
+ color: #000000;
+ font-size: 14px;
+ font-family: helvetica, arial, sans-serif;
+ page-break-after: avoid;
+}
+h3
+{
+ color: #000000;
+ font-size: 13px;
+ font-family: helvetica, arial, sans-serif;
+ page-break-after: avoid;
+}
+li
+{
+ margin-left: 2em;
+ margin-right: 2em;
+}
+ol
+{
+ margin-left: 2em;
+ margin-right: 2em;
+}
+p
+{
+ margin-left: 2em;
+ margin-right: 2em;
+}
+pre
+{
+ margin-left: 3em;
+ background-color: lightyellow;
+}
+tt {
+font-face: courier;
+}
+table
+{
+ margin-left: 2em;
+ font-size: 13px;
+}
+td.top
+{
+ vertical-align: top;
+}
+td.topnowrap
+{
+ vertical-align: top;
+ white-space: nowrap;
+}
+td.right
+{
+ text-align: right;
+}
+td.header
+{
+ width: 33%;
+ color: #ffffff;
+ background-color: #666666;
+ font-size: 10px;
+ font-family: arial, helvetica, sans-serif;
+ vertical-align: top
+}
+.editingmark
+{
+ background-color: khaki;
+}
+.hotText
+{
+ color:#ffffff;
+ font-weight: normal;
+ text-decoration: none;
+ font-family: chelvetica, arial, sans-serif;
+ font-size: 9px
+}
+.link2
+{
+ color:#ffffff;
+ font-weight: bold;
+ text-decoration: none;
+ font-family: helvetica, arial, sans-serif;
+ font-size: 9px
+}
+.toowide
+{
+ color: red;
+ font-weight: bold;
+}
+.RFC
+{
+ color:#666666;
+ font-weight: bold;
+ text-decoration: none;
+ font-family: helvetica, arial, sans-serif;
+ font-size: 9px
+}
+.title
+{
+ color: #990000;
+ font-size: 22px;
+ line-height: 22px;
+ font-weight: bold;
+ text-align: right;
+ font-family: helvetica, arial, sans-serif
+}
+.figure
+{
+ font-weight: bold;
+ text-align: center;
+ font-size: 12px;
+}
+.filename
+{
+ color: #333333;
+ font-weight: bold;
+ font-size: 16px;
+ line-height: 24px;
+ font-family: helvetica, arial, sans-serif;
+ text-align: right;
+}
+
+del
+{
+ color: red;
+}
+
+ins
+{
+ color: blue;
+}
+table.resolution
+{
+ background-color: khaki;
+ border-width: thin;
+ border-style: solid;
+ border-color: black;
+ margin-left: auto;
+ margin-right: 0;
+ float: right;
+}
+
+ at media print {
+ .noprint {display:none}
+}
+</style>
+<link rel="Contents" href="#rfc.toc">
+<link rel="Author" href="#rfc.authors">
+<link rel="Copyright" href="#rfc.copyright">
+<link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
+<link rel="Chapter" title="2 Administration" href="#rfc.section.2">
+<link rel="Chapter" title="3 Abstractions" href="#rfc.section.3">
+<link rel="Chapter" title="4 Element definitions" href="#rfc.section.4">
+<link rel="Chapter" title="5 Requirements for XSPF generators" href="#rfc.section.5">
+<link rel="Chapter" title="6 Requirements for XSPF players" href="#rfc.section.6">
+<link rel="Chapter" title="7 Usecases for playlists" href="#rfc.section.7">
+<link rel="Chapter" title="8 Recipes" href="#rfc.section.8">
+<link rel="Appendix" title="A IANA Considerations" href="#rfc.section.A">
+<link rel="schema.DC" href="http://purl.org/dc">
+<meta name="DC.Creator" content="Lucas Gonze, Matthias Friedrich, Robert Kaye, Dave Brown">
+</head>
+<body>
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;">
+<tr><td style="background-color: #000000; text-align: center; vertical-align: middle; height: 2.5em;"><b><span class="RFC"> RFC </span></b></td></tr>
+<tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr>
+</table>
+<table summary="header information" width="66%" border="0" cellpadding="1" cellspacing="1">
+<tr>
+<td class="header">Playlist Ad-Hoc Group </td>
+<td class="header">L. Gonze </td>
+</tr>
+<tr>
+<td class="header">INTERNET DRAFT </td>
+<td class="header">M. Friedrich </td>
+</tr>
+<tr>
+<td class="header">
+ <xspf-v1-draft1>
+ </td>
+<td class="header">R. Kaye </td>
+</tr>
+<tr>
+<td class="header">
+ Category:
+ Informational </td>
+<td class="header">D. Brown </td>
+</tr>
+<tr>
+<td class="header">Expires: July 2005 </td>
+<td class="header">January 2005 </td>
+</tr>
+</table>
+<p class="title">XSPF Version 1<br><span class="filename">XML Shareable Playlist Format ("spiff")</span>
+</p>
+<h1>Abstract</h1>
+<p>We describe an XML playlist format which is open,
+ moderately simple, and carefully engineered.</p>
+<hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;">
+<tr><td style="background-color: #000000; text-align: center; vertical-align: middle; height: 2.5em;"><b><span class="RFC"> RFC </span></b></td></tr>
+<tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr>
+</table>
+<h1><a name="rfc.toc">Table of Contents</a></h1>
+<p>
+
+ <b>1
+ <a href="#rfc.section.1">Introduction</a></b><br>
+
+
+
+
+
+
+ <b> 1.1
+ <a href="#rfc.section.1.1">Example</a></b><br>
+
+
+
+
+
+
+
+ <b>2
+ <a href="#rfc.section.2">Administration</a></b><br>
+
+ <b> 2.1
+ <a href="#rfc.section.2.1">History</a></b><br>
+
+
+
+
+
+
+
+
+
+ <b> 2.2
+ <a href="#rfc.section.2.2">Acknowledgements</a></b><br>
+
+
+
+ <b> 2.3
+ <a href="#rfc.section.2.3">terminology</a></b><br>
+
+ <b> 2.3.1
+ <a href="#rfc.section.2.3.1">URI, URLs and URNs</a></b><br>
+
+
+
+
+ <b> 2.3.2
+ <a href="#rfc.section.2.3.2">Requirements notation</a></b><br>
+
+
+
+
+
+
+
+ <b>3
+ <a href="#rfc.section.3">Abstractions</a></b><br>
+
+ <b> 3.1
+ <a href="#rfc.section.3.1">Defining playlists</a></b><br>
+
+
+
+
+ <b> 3.2
+ <a href="#rfc.section.3.2">What a playlist is not</a></b><br>
+
+
+
+
+
+
+
+
+
+ <b> 3.3
+ <a href="#rfc.section.3.3">Shareability</a></b><br>
+
+
+
+
+
+
+
+ <b> 3.4
+ <a href="#rfc.section.3.4">Content resolver</a></b><br>
+
+
+
+
+
+
+
+
+
+
+ <b> 3.5
+ <a href="#rfc.section.3.5">Fuzzy names</a></b><br>
+
+
+
+
+
+
+<b>4
+ <a href="#rfc.section.4">Element definitions</a></b><br>
+ <b> 4.1
+ <a href="#rfc.section.4.1">elements</a></b><br>
+ <b> 4.1.1
+ <a href="#rfc.section.4.1.1">playlist</a></b><br>
+
+ <b> 4.1.1.1
+ <a href="#rfc.section.4.1.1.1">attributes</a></b><br>
+ <b> 4.1.1.1.1
+ <a href="#rfc.section.4.1.1.1.1">xmlns</a></b><br>
+
+
+ <b> 4.1.1.1.2
+ <a href="#rfc.section.4.1.1.1.2">version</a></b><br>
+
+
+
+
+
+ <b> 4.1.1.2
+ <a href="#rfc.section.4.1.1.2">elements</a></b><br>
+
+ <b> 4.1.1.2.1
+ <a href="#rfc.section.4.1.1.2.1">title</a></b><br>
+
+
+
+ <b> 4.1.1.2.2
+ <a href="#rfc.section.4.1.1.2.2">creator</a></b><br>
+
+
+
+ <b> 4.1.1.2.3
+ <a href="#rfc.section.4.1.1.2.3">annotation</a></b><br>
+
+
+
+ <b> 4.1.1.2.4
+ <a href="#rfc.section.4.1.1.2.4">info</a></b><br>
+
+
+
+ <b> 4.1.1.2.5
+ <a href="#rfc.section.4.1.1.2.5">location</a></b><br>
+
+
+
+ <b> 4.1.1.2.6
+ <a href="#rfc.section.4.1.1.2.6">identifier</a></b><br>
+
+
+
+ <b> 4.1.1.2.7
+ <a href="#rfc.section.4.1.1.2.7">image</a></b><br>
+
+
+
+ <b> 4.1.1.2.8
+ <a href="#rfc.section.4.1.1.2.8">date</a></b><br>
+
+
+
+
+
+
+
+
+ <b> 4.1.1.2.9
+ <a href="#rfc.section.4.1.1.2.9">license</a></b><br>
+
+
+
+ <b> 4.1.1.2.10
+ <a href="#rfc.section.4.1.1.2.10">attribution</a></b><br>
+
+
+
+
+
+ <b> 4.1.1.2.11
+ <a href="#rfc.section.4.1.1.2.11">link</a></b><br>
+
+
+ <b> 4.1.1.2.11.1
+ <a href="#rfc.section.4.1.1.2.11.1">attributes</a></b><br>
+ <b> 4.1.1.2.11.1.1
+ <a href="#rfc.section.4.1.1.2.11.1.1">rel</a></b><br>
+
+
+
+ <b> 4.1.1.2.11.2
+ <a href="#rfc.section.4.1.1.2.11.2">content</a></b><br>
+
+
+
+
+ <b> 4.1.1.2.12
+ <a href="#rfc.section.4.1.1.2.12">meta</a></b><br>
+
+
+ <b> 4.1.1.2.12.1
+ <a href="#rfc.section.4.1.1.2.12.1">attributes</a></b><br>
+ <b> 4.1.1.2.12.1.1
+ <a href="#rfc.section.4.1.1.2.12.1.1">rel</a></b><br>
+
+
+
+ <b> 4.1.1.2.12.2
+ <a href="#rfc.section.4.1.1.2.12.2">content</a></b><br>
+
+
+
+
+
+ <b> 4.1.1.2.13
+ <a href="#rfc.section.4.1.1.2.13">extension</a></b><br>
+
+
+ <b> 4.1.1.2.13.1
+ <a href="#rfc.section.4.1.1.2.13.1">attributes</a></b><br>
+ <b> 4.1.1.2.13.1.1
+ <a href="#rfc.section.4.1.1.2.13.1.1">application</a></b><br>
+
+
+
+ <b> 4.1.1.2.13.2
+ <a href="#rfc.section.4.1.1.2.13.2">content</a></b><br>
+
+
+
+
+ <b> 4.1.1.2.14
+ <a href="#rfc.section.4.1.1.2.14">trackList</a></b><br>
+
+
+
+
+
+
+ <b> 4.1.1.2.14.1
+ <a href="#rfc.section.4.1.1.2.14.1">elements</a></b><br>
+ <b> 4.1.1.2.14.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1">track</a></b><br>
+ <b> 4.1.1.2.14.1.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1">elements</a></b><br>
+
+ <b> 4.1.1.2.14.1.1.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.1">location</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.2
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.2">identifier</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.3
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.3">title</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.4
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.4">creator</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.5
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.5">annotation</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.6
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.6">info</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.7
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.7">image</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.8
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.8">album</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.9
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.9">trackNum</a></b><br>
+
+
+
+
+ <b> 4.1.1.2.14.1.1.1.10
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.10">duration</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.11
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.11">link</a></b><br>
+
+
+ <b> 4.1.1.2.14.1.1.1.11.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.11.1">attributes</a></b><br>
+ <b> 4.1.1.2.14.1.1.1.11.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.11.1.1">rel</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.11.2
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.11.2">content</a></b><br>
+
+
+
+
+ <b> 4.1.1.2.14.1.1.1.12
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.12">meta</a></b><br>
+
+
+ <b> 4.1.1.2.14.1.1.1.12.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.12.1">attributes</a></b><br>
+ <b> 4.1.1.2.14.1.1.1.12.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.12.1.1">rel</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.12.2
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.12.2">content</a></b><br>
+
+
+
+
+ <b> 4.1.1.2.14.1.1.1.13
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.13">extension</a></b><br>
+
+
+ <b> 4.1.1.2.14.1.1.1.13.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.13.1">attributes</a></b><br>
+ <b> 4.1.1.2.14.1.1.1.13.1.1
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.13.1.1">application</a></b><br>
+
+
+
+ <b> 4.1.1.2.14.1.1.1.13.2
+ <a href="#rfc.section.4.1.1.2.14.1.1.1.13.2">content</a></b><br>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <b>5
+ <a href="#rfc.section.5">Requirements for XSPF generators</a></b><br>
+
+
+
+ <b>6
+ <a href="#rfc.section.6">Requirements for XSPF players</a></b><br>
+
+ <b> 6.1
+ <a href="#rfc.section.6.1">Graceful failure</a></b><br>
+
+
+
+
+ <b> 6.2
+ <a href="#rfc.section.6.2">Relative paths</a></b><br>
+
+
+
+
+
+ <b> 6.3
+ <a href="#rfc.section.6.3">Extension URIs</a></b><br>
+
+
+
+
+
+ <b>7
+ <a href="#rfc.section.7">Usecases for playlists</a></b><br>
+
+ <b> 7.1
+ <a href="#rfc.section.7.1">Flag player application</a></b><br>
+
+
+
+
+
+
+
+
+
+ <b> 7.2
+ <a href="#rfc.section.7.2">Allow streaming</a></b><br>
+
+
+
+
+
+
+
+
+
+ <b> 7.3
+ <a href="#rfc.section.7.3">Collecting fragmented resources</a></b><br>
+
+
+
+
+
+
+
+
+
+ <b> 7.4
+ <a href="#rfc.section.7.4">Alternate media types</a></b><br>
+
+
+
+
+
+
+
+ <b> 7.5
+ <a href="#rfc.section.7.5">Caching derived info</a></b><br>
+
+
+
+
+
+
+ <b> 7.6
+ <a href="#rfc.section.7.6">Metadata storage</a></b><br>
+
+
+
+
+
+
+ <b> 7.7
+ <a href="#rfc.section.7.7">Authoring compilations for expressive reasons</a></b><br>
+
+
+
+
+
+
+
+
+
+
+ <b>8
+ <a href="#rfc.section.8">Recipes</a></b><br>
+
+ <b> 8.1
+ <a href="#rfc.section.8.1">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></b><br>
+
+
+
+ <b> 8.2
+ <a href="#rfc.section.8.2">How to I convert XSPF to M3U?</a></b><br>
+
+
+
+ <b> 8.3
+ <a href="#rfc.section.8.3">How to I convert XSPF to HTML?</a></b><br>
+
+
+
+ <b> 8.4
+ <a href="#rfc.section.8.4">How to I convert XSPF to SMIL?</a></b><br>
+
+
+
+ <b> 8.5
+ <a href="#rfc.section.8.5">How to I convert XSPF to Soundblox?</a></b><br>
+
+
+
+ <b> 8.6
+ <a href="#rfc.section.8.6">How do I customize XSPF? Should I use namespaces?</a></b><br>
+
+
+
+ <b> 8.7
+ <a href="#rfc.section.8.7">How do I validate XSPF?</a></b><br>
+
+
+
+
+
+
+
+ <b> 8.8
+ <a href="#rfc.section.8.8">How do I use MusicBrainz metadata?</a></b><br>
+
+
+
+
+ <b> 8.9
+ <a href="#rfc.section.8.9">How do I refer to a BitTorrent?</a></b><br>
+
+
+
+ <b> 8.10
+ <a href="#rfc.section.8.10">How do I refer to a Magnet or sha1: URI?</a></b><br>
+
+
+
+
+ <b>§
+ <a href="#rfc.references">References</a></b><br><b>§
+ <a href="#rfc.authors">Author's Addresses</a></b><br><b>A
+ <a href="#rfc.section.A">IANA Considerations</a></b><br>
+
+ <b> A.1
+ <a href="#rfc.section.A.1">MIME media type name</a></b><br>
+
+
+
+ <b> A.2
+ <a href="#rfc.section.A.2">MIME subtype name</a></b><br>
+
+
+
+
+ <b> A.3
+ <a href="#rfc.section.A.3">Mandatory parameters</a></b><br>
+
+
+
+ <b> A.4
+ <a href="#rfc.section.A.4">Optional parameters</a></b><br>
+
+
+
+ <b> A.5
+ <a href="#rfc.section.A.5">Translated into plain english</a></b><br>
+
+
+
+ <b> A.6
+ <a href="#rfc.section.A.6">File extension</a></b><br>
+
+
+
+ <b> A.7
+ <a href="#rfc.section.A.7">Security Considerations</a></b><br>
+
+
+
+ <b>§
+ <a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></b><br>
+</p>
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.1">1</a>
+ Introduction</h1>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.1.p.1"></a></div>
+<p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+<div><a name="rfc.section.1.p.2"></a></div>
+<p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format
+ are proprietary. ASX resembles XML in that it uses angle
+ brackets, but is not XML by any means. M3U, RAM, and M4U are
+ flat files; QuickTime is binary; Pls is in the Windows .ini
+ format; Gnomoradio RDF is RDF, not XML. SMIL addresses a much
+ larger problem space than the average MP3 player. The timing
+ model of RSS doesn't fit audio and video. Forcing timing
+ models into HTML, as HTML+Time does, creates an unintelligible
+ feature set. Few of these formats are well documented. None
+ of these formats make simple features easy to code and hard
+ features possible. Only one is an open standard. Not one
+ offers playlist interoperability across major vendors.</p>
+<div><a name="rfc.section.1.p.3"></a></div>
+<p>The question for software developers is <em>why should I support this new XML playlist
+ format</em>? The choice is mainly between M3U and SMIL.
+ Almost every MP3 player accepts M3U but also invents an XML
+ playlist format. Inventing a format creates work, for
+ example to study related formats; you should use XSPF to
+ avoid the work. SMIL, on the other hand, is a prescription
+ for a kind of application that is different from an MP3
+ player -- it describes layouts in time, while XSPF describes
+ concepts common among MP3 players. Given a song with the
+ comment "danceable!", SMIL might have an instruction to
+ write that text in the upper left in a bold sans-serif font,
+ while XSPF would tell an MP3 player that the text is a
+ comment and say nothing about formatting.</p>
+<h2>
+<a name="rfc.section.1.1">1.1</a>
+ Example</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.figure.u.1"></a></div>
+ <p>A very simple document looks like this:</p>
+ <pre><?xml version="1.0" encoding="UTF-8"?>
+<playlist version="1" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/song_1.mp3</location></track>
+ <track><location>file:///mp3s/song_2.mp3</location></track>
+ <track><location>file:///mp3s/song_3.mp3</location></track>
+ </trackList>
+</playlist>
+
+</pre>
+ <div><a name="rfc.figure.u.2"></a></div>
+ <p>or this:</p>
+ <pre><?xml version="1.0" encoding="UTF-8"?>
+<playlist version="1" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>http://example.com/song_1.mp3</location></track>
+ <track><location>http://example.com/song_2.mp3</location></track>
+ <track><location>http://example.com/song_3.mp3</location></track>
+ </trackList>
+</playlist>
+
+</pre>
+ </div>
+</div>
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.2">2</a>
+ Administration</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.2.1">2.1</a>
+ History</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.2.1.p.1"></a></div>
+<p>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. Version 1 is not far from being frozen and
+ code-ready.</p>
+<div><a name="rfc.section.2.1.p.2"></a></div>
+<p>This document describes version 1, which is not ready for
+ implementation. Version 0, the previous one, is stable and
+ frozen -- developers can assume that it will not change.</p>
+<div><a name="rfc.section.2.1.p.3"></a></div>
+<p>The home of our working group on the web is
+ http://xspf.org.</p>
+</div>
+<h2>
+<a name="rfc.section.2.2">2.2</a>
+ Acknowledgements</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.2.2.p.1"></a></div>
+<p>We have benefitted a great deal from the contributions of
+ Dan Brickley, Kevin Marks and Ian C. Rogers, each of whom
+ strongly influenced the shape of the format. We are
+ grateful for comments and feedback from Ryan Shaw, Alf
+ Eaton, Steve Gedikian, Russell Garrett, and Ben Tesch.
+ 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.</p>
+</div>
+<h2>
+<a name="rfc.section.2.3">2.3</a>
+ terminology</h2>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.2.3.1">2.3.1</a>
+ URI, URLs and URNs</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.2.3.1.p.1"></a></div>
+<p>The terms URI, URL, and URN should be interpreted here as
+ follows: a URL is an address of something that can be
+ fetched by a computer; a URN is a name of something which
+ may be purely an abstraction; a URI is either. In this
+ document, //playlist[@xmlns], //playlist/identifier,
+ meta[@rel], link[@rel], and
+ //playlist/trackList/track/identifier are URNs, all other
+ elements are URLs.</p>
+<div><a name="rfc.section.2.3.1.p.2"></a></div>
+<p>See also: <a href="#http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html">RFC2396bis</a>; <a href="#http://www.w3.org/TR/uri-clarification/">URIs, URLs, and URNs: Clarifications and Recommendations 1.0</a>
+</p>
+</div>
+<h3>
+<a name="rfc.section.2.3.2">2.3.2</a>
+ Requirements notation</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.2.3.2.p.1"></a></div>
+<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+ "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
+ "MAY", and "OPTIONAL" in this document MUST NOT be
+ interpreted as described in <a href="#RFC2119" title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</a>.
+ In this document these should be interpreted to mean
+ that something shouted is important. XSPF is not a
+ standards track document, it is an ad-hoc project by a
+ group of individuals. Developers may, however, find
+ that <a href="#RFC2119" title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</a> is a useful source
+ anyway.</p>
+</div>
+</div>
+</div>
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.3">3</a>
+ Abstractions</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.3.1">3.1</a>
+ Defining playlists</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.3.1.p.1"></a></div>
+<p>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.</p>
+</div>
+<h2>
+<a name="rfc.section.3.2">3.2</a>
+ What a playlist is not</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.3.2.p.1"></a></div>
+<p>The function of a playlist <em>is not</em> 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 <em>link</em>
+ and <em>meta</em> elements are
+ for.</p>
+<div><a name="rfc.section.3.2.p.2"></a></div>
+<p>The function of a playlist <em>is not</em> 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 <em>catalog</em>.</p>
+<div><a name="rfc.section.3.2.p.3"></a></div>
+<p>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.</p>
+</div>
+<h2>
+<a name="rfc.section.3.3">3.3</a>
+ Shareability</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.3.3.p.1"></a></div>
+<p>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.</p>
+<div><a name="rfc.section.3.3.p.2"></a></div>
+<p>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.</p>
+<div><a name="rfc.section.3.3.p.3"></a></div>
+<p>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 URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+</div>
+<h2>
+<a name="rfc.section.3.4">3.4</a>
+ Content resolver</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.3.4.p.1"></a></div>
+<p>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.</p>
+<div><a name="rfc.section.3.4.p.2"></a></div>
+<p>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 <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+<div><a name="rfc.section.3.4.p.3"></a></div>
+<p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> 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.</p>
+<div><a name="rfc.section.3.4.p.4"></a></div>
+<p>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.</p>
+</div>
+<h2>
+<a name="rfc.section.3.5">3.5</a>
+ Fuzzy names</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.3.5.p.1"></a></div>
+<p>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, 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.</p>
+</div>
+</div>
+
+
+<hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.4">4</a>
+ Element definitions</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.4.1">4.1</a>
+ elements</h2>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1">4.1.1</a>
+ playlist</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.1">4.1.1.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.1.1">4.1.1.1.1</a>
+ xmlns</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.1.1.p.1"></a></div>
+<p>http://xspf.org/ns/0/</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.1.2">4.1.1.1.2</a>
+ version</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.1.2.p.1"></a></div>
+<p>1</p>
+</div>
+<div><a name="rfc.section.4.1.1.1.p.1"></a></div>
+<p>Notice that the namespace is 0 but the version is 1. This is because version 1 playlists are backwards compatible with version 0 parsers.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2">4.1.1.2</a>
+ elements</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.1">4.1.1.2.1</a>
+ title</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.1.p.1"></a></div>
+<p>A human-readable title for the
+ playlist. xspf:playlist elements MAY contain exactly
+ one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.2">4.1.1.2.2</a>
+ creator</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.2.p.1"></a></div>
+<p>Human-readable name of the entity (author, authors,
+ group, company, etc) that authored the
+ playlist. xspf:playlist elements MAY contain exactly
+ one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.3">4.1.1.2.3</a>
+ annotation</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.3.p.1"></a></div>
+<p>A human-readable comment on the playlist. This is
+ character data, not HTML, and it may not contain
+ markup. xspf:playlist elements MAY contain exactly
+ one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.4">4.1.1.2.4</a>
+ info</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.4.p.1"></a></div>
+<p>URL of a web page to find out more about this
+ playlist. Likely to be homepage of the author, and would
+ be used to find out more about the author and to find
+ more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.5">4.1.1.2.5</a>
+ location</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.5.p.1"></a></div>
+<p>Source URL for this playlist. xspf:playlist elements
+ MAY contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.6">4.1.1.2.6</a>
+ identifier</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.6.p.1"></a></div>
+<p>Canonical ID for this playlist. Likely to be a hash
+ or other location-independent name. MUST be a legal
+ URN. xspf:playlist elements MAY contain exactly
+ one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.7">4.1.1.2.7</a>
+ image</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.7.p.1"></a></div>
+<p>URL of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist
+ elements MAY contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.8">4.1.1.2.8</a>
+ date</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.8.p.1"></a></div>
+<p>Creation date (not last-modified date) of the playlist,
+ formatted as a <a href="#http://www.w3.org/TR/xmlschema-2/#dateTime">XML
+ schema dateTime</a>. xspf:playlist elements MAY contain
+ exactly one.</p>
+<div><a name="rfc.figure.u.3"></a></div>
+ <p>A sample date is
+ "2005-01-08T17:10:47-05:00". PHP to produce such a
+ string from a unix timestamp is:</p>
+ <pre>$main_date = date("Y-m-d\TH:i:s", $timestamp);
+$tz = date("O", $timestamp);
+$tz = substr_replace ($tz, ':', 3, 0);
+
+</pre>
+ <div><a name="rfc.section.4.1.1.2.8.p.3"></a></div>
+<p>Note: in version 0 of XSPF, this was specifed as an ISO
+ 8601 date. xsd:dateTime is the same thing (with better
+ documentation) for almost every date in history, and there
+ are no playlist creation dates that might be different.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.9">4.1.1.2.9</a>
+ license</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.9.p.1"></a></div>
+<p>URL of a resource that describes the license under
+ which this playlist was released. xspf:playlist
+ elements may contain zero or one license element.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.10">4.1.1.2.10</a>
+ attribution</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.10.p.1"></a></div>
+<p>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 or //playlist/identifier element
+ to the top of the items in the //playlist/attribution
+ element. xspf:playlist elements MAY contain exactly
+ one xspf:attribution element.</p>
+<div><a name="rfc.section.4.1.1.2.10.p.2"></a></div>
+<p>Such a list can grow without limit, so as a
+ practical matter we suggest deleting ancestors more
+ than ten generations back.</p>
+<div><a name="rfc.figure.u.4"></a></div>
+ <pre><attribution>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <identifier>somescheme:original_playlist.xspf</identifier>
+</attribution>
+</pre>
+ </div>
+<h3>
+<a name="rfc.section.4.1.1.2.11">4.1.1.2.11</a>
+ link</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.11.p.1"></a></div>
+<p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more link elements.</p>
+<div><a name="rfc.figure.u.5"></a></div>
+ <pre><link rel="http://foaf.example.org/namespace/version1">http://socialnetwork.example.org/foaf/mary.rdfs</link>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.11.1">4.1.1.2.11.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.11.1.1">4.1.1.2.11.1.1</a>
+ rel</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.11.1.1.p.1"></a></div>
+<p>URI of a resource type.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.11.2">4.1.1.2.11.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.11.2.p.1"></a></div>
+<p>URL of a resource.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.12">4.1.1.2.12</a>
+ meta</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.12.p.1"></a></div>
+<p>The meta element allows non-XSPF metadata to be
+ included in XSPF documents without breaking XSPF
+ validation. xspf:playlist elements MAY contain zero
+ or more meta elements.</p>
+<div><a name="rfc.figure.u.6"></a></div>
+ <pre><meta rel="http://example.org/key">value</meta>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.12.1">4.1.1.2.12.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.12.1.1">4.1.1.2.12.1.1</a>
+ rel</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.12.1.1.p.1"></a></div>
+<p>URI of a resource defining the metadata.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.12.2">4.1.1.2.12.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.12.2.p.1"></a></div>
+<p>Value of the metadata element. This is plain old
+ text, not XML, and it may not contain markup.
+ xspf:playlist elements MAY contain exactly one.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.13">4.1.1.2.13</a>
+ extension</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.13.p.1"></a></div>
+<p>The extension element allows non-XSPF XML to be included
+ in XSPF documents without breaking XSPF validation. The
+ purpose is to allow nested XML, which the meta and link
+ elements do not. xspf:playlist elements MAY contain zero
+ or more extension elements.</p>
+<div><a name="rfc.figure.u.7"></a></div>
+ <pre><playlist xmlns:cl="http://example.com">
+ <extension application="http://example.com">
+ <cl:clip start="25000" end="34500"/>
+ </extension>
+</playlist>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.13.1">4.1.1.2.13.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.13.1.1">4.1.1.2.13.1.1</a>
+ application</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.13.1.1.p.1"></a></div>
+<p>URI of a resource defining the structure and purpose
+ of the nested XML.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.13.2">4.1.1.2.13.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.13.2.p.1"></a></div>
+<p>nested XML.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14">4.1.1.2.14</a>
+ trackList</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.p.1"></a></div>
+<p>Ordered list of xspf:track elements to be rendered.
+ The sequence is a hint, not a requirement; renderers
+ are advised to play tracks from top to bottom unless
+ there is an indication otherwise.</p>
+<div><a name="rfc.section.4.1.1.2.14.p.2"></a></div>
+<p>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.</p>
+<div><a name="rfc.section.4.1.1.2.14.p.3"></a></div>
+<p>xspf:playlist elements MUST contain one and only one
+ trackList element. The trackList element my be empty.</p>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1">4.1.1.2.14.1</a>
+ elements</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1">4.1.1.2.14.1.1</a>
+ track</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1">4.1.1.2.14.1.1.1</a>
+ elements</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.1">4.1.1.2.14.1.1.1.1</a>
+ location</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.1.p.1"></a></div>
+<p>URL of resource to be rendered. Probably an
+ audio resource, but MAY be any type of
+ resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF
+ document. The duration of the resource defined
+ in this element defines the duration of
+ rendering. xspf:track elements MAY contain
+ zero or more location elements, but a
+ user-agent MUST NOT render more than one of
+ the named resources.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.2">4.1.1.2.14.1.1.1.2</a>
+ identifier</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.2.p.1"></a></div>
+<p>Canonical ID for this resource. Likely to
+ be a hash or other location-independent
+ name, such as a MusicBrainz identifier or
+ isbn URN (if there existed isbn numbers for
+ audio). MUST be a legal URN. xspf:playlist
+ elements MAY contain zero or more identifier
+ elements.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.3">4.1.1.2.14.1.1.1.3</a>
+ title</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.3.p.1"></a></div>
+<p>Human-readable name of the track that
+ authored the resource which defines the
+ duration of track rendering. This value is
+ primarily for fuzzy lookups, though a
+ user-agent may display it. xspf:track
+ elements MAY contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.4">4.1.1.2.14.1.1.1.4</a>
+ creator</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.4.p.1"></a></div>
+<p>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.5">4.1.1.2.14.1.1.1.5</a>
+ annotation</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.5.p.1"></a></div>
+<p>A human-readable comment on the track. This
+ is character data, not HTML, and it may not
+ contain markup. xspf:track elements MAY
+ contain exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.6">4.1.1.2.14.1.1.1.6</a>
+ info</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.6.p.1"></a></div>
+<p>URL of a place where this resource can be
+ bought or more info can be found.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.7">4.1.1.2.14.1.1.1.7</a>
+ image</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.7.p.1"></a></div>
+<p>URL of an image to display for the duration
+ of the track. xspf:track elements MAY contain
+ exactly one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.8">4.1.1.2.14.1.1.1.8</a>
+ album</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.8.p.1"></a></div>
+<p>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.9">4.1.1.2.14.1.1.1.9</a>
+ trackNum</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.9.p.1"></a></div>
+<p>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.10">4.1.1.2.14.1.1.1.10</a>
+ duration</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.10.p.1"></a></div>
+<p>The time to render a resource, in
+ milliseconds. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value
+ is only a hint -- different XSPF generators
+ will generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</p>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.11">4.1.1.2.14.1.1.1.11</a>
+ link</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.p.1"></a></div>
+<p>The link element allows non-XSPF web
+ resources to be included in xspf:track
+ elements without breaking XSPF
+ validation.</p>
+<div><a name="rfc.figure.u.8"></a></div>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.11.1">4.1.1.2.14.1.1.1.11.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.11.1.1">4.1.1.2.14.1.1.1.11.1.1</a>
+ rel</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.1.1.p.1"></a></div>
+<p>URN of a resource type.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.11.2">4.1.1.2.14.1.1.1.11.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.2.p.1"></a></div>
+<p>URL of a resource.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.12">4.1.1.2.14.1.1.1.12</a>
+ meta</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.12.p.1"></a></div>
+<p>The meta element allows non-XSPF metadata
+ to be included in xspf:track elements
+ without breaking XSPF validation.</p>
+<div><a name="rfc.figure.u.9"></a></div>
+ <pre><meta rel="http://example.org/key">value</meta>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.12.1">4.1.1.2.14.1.1.1.12.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.12.1.1">4.1.1.2.14.1.1.1.12.1.1</a>
+ rel</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.12.1.1.p.1"></a></div>
+<p>URN of a resource defining the metadata.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.12.2">4.1.1.2.14.1.1.1.12.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.12.2.p.1"></a></div>
+<p>Value of the metadata element. This is
+ character data, not HTML, and it may not
+ contain markup. xspf:playlist elements MAY
+ contain exactly one.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.13">4.1.1.2.14.1.1.1.13</a>
+ extension</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.13.p.1"></a></div>
+<p>The extension element allows non-XSPF XML to be included
+ in XSPF documents without breaking XSPF validation. The
+ purpose is to allow nested XML, which the meta and link
+ elements do not. xspf:playlist elements MAY contain zero
+ or more extension elements.</p>
+<div><a name="rfc.figure.u.10"></a></div>
+ <pre><playlist xmlns:cl="http://example.com">
+ <trackList>
+ <track>
+ <extension application="http://example.com">
+ <cl:clip start="25000" end="34500"/>
+ </extension>
+ </track>
+ </trackList>
+</playlist>
+
+</pre>
+ <h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.13.1">4.1.1.2.14.1.1.1.13.1</a>
+ attributes</h3>
+<div style="margin-left: 8px;">
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.13.1.1">4.1.1.2.14.1.1.1.13.1.1</a>
+ application</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.13.1.1.p.1"></a></div>
+<p>URI of a resource defining the structure and purpose
+ of the nested XML.</p>
+</div>
+</div>
+<h3>
+<a name="rfc.section.4.1.1.2.14.1.1.1.13.2">4.1.1.2.14.1.1.1.13.2</a>
+ content</h3>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.13.2.p.1"></a></div>
+<p>nested XML.</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+
+
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.5">5</a>
+ Requirements for XSPF generators</h1>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.5.p.1"></a></div>
+<p>To ensure interoperability, conforming applications MUST
+ generate playlists that follow the definitions listed in
+ section 4 (element descriptions). <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">A
+ Relax NG schema</a> has been provided to test for
+ syntactic conformance.</p>
+</div>
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.6">6</a>
+ Requirements for XSPF players</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.6.1">6.1</a>
+ Graceful failure</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.6.1.p.1"></a></div>
+<p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+</div>
+<h2>
+<a name="rfc.section.6.2">6.2</a>
+ Relative paths</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.6.2.p.1"></a></div>
+<p>Relative paths MUST be resolved according to the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+<pre>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.
+
+</pre>
+</div>
+<h2>
+<a name="rfc.section.6.3">6.3</a>
+ Extension URIs</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.6.3.p.1"></a></div>
+<p>Applications MUST assign unique URNs from their own
+ namespace for each link, meta and extension element. New
+ URNs SHOULD be assigned if syntax and/or semantics of a
+ link, meta or extension element changes.
+ </p>
+</div>
+</div>
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.7">7</a>
+ Usecases for playlists</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.7.1">7.1</a>
+ Flag player application</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.1.p.1"></a></div>
+<p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+<div><a name="rfc.section.7.1.p.2"></a></div>
+<p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+<div><a name="rfc.section.7.1.p.3"></a></div>
+<p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+</div>
+<h2>
+<a name="rfc.section.7.2">7.2</a>
+ Allow streaming</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.2.p.1"></a></div>
+<p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+<div><a name="rfc.section.7.2.p.2"></a></div>
+<p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+<div><a name="rfc.section.7.2.p.3"></a></div>
+<p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+</div>
+<h2>
+<a name="rfc.section.7.3">7.3</a>
+ Collecting fragmented resources</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.3.p.1"></a></div>
+<p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+<div><a name="rfc.section.7.3.p.2"></a></div>
+<p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+<div><a name="rfc.section.7.3.p.3"></a></div>
+<p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+</div>
+<h2>
+<a name="rfc.section.7.4">7.4</a>
+ Alternate media types</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.4.p.1"></a></div>
+<p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+<div><a name="rfc.section.7.4.p.2"></a></div>
+<p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URL within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+<div><a name="rfc.section.7.4.p.3"></a></div>
+<p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+</div>
+<h2>
+<a name="rfc.section.7.5">7.5</a>
+ Caching derived info</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.5.p.1"></a></div>
+<p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+<div><a name="rfc.section.7.5.p.2"></a></div>
+<p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+<div><a name="rfc.section.7.5.p.3"></a></div>
+<p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+</div>
+<h2>
+<a name="rfc.section.7.6">7.6</a>
+ Metadata storage</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.6.p.1"></a></div>
+<p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+<div><a name="rfc.section.7.6.p.2"></a></div>
+<p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+<div><a name="rfc.section.7.6.p.3"></a></div>
+<p>XSPF' solution: XSPF defers this functionality to other
+ sources. Metadata is hard; there are already many
+ projects to deal with it, some of which are very good.
+ Metadata is attached to an XSPF track according to
+ whatever syntax an imported vocabulary defines. XML
+ namespaces may be used, but the preferred syntax is the
+ XSPF <em>link</em> and <em>meta</em> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+</div>
+<h2>
+<a name="rfc.section.7.7">7.7</a>
+ Authoring compilations for expressive reasons</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.7.7.p.1"></a></div>
+<p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+<div><a name="rfc.section.7.7.p.2"></a></div>
+<p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URLs, into a file in the
+ M3U format.</p>
+<div><a name="rfc.section.7.7.p.3"></a></div>
+<p>XSPF' solution: The XSPF <em>trackList</em> element contains a
+ sequence of <em>track</em> elements,
+ each of which points to one of the objects.</p>
+</div>
+</div>
+
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.8">8</a>
+ Recipes</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.8.1">8.1</a>
+ How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.1.p.1"></a></div>
+<p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>.</p>
+</div>
+<h2>
+<a name="rfc.section.8.2">8.2</a>
+ How to I convert XSPF to M3U?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.2.p.1"></a></div>
+<p>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</p>
+</div>
+<h2>
+<a name="rfc.section.8.3">8.3</a>
+ How to I convert XSPF to HTML?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.3.p.1"></a></div>
+<p>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</p>
+</div>
+<h2>
+<a name="rfc.section.8.4">8.4</a>
+ How to I convert XSPF to SMIL?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.4.p.1"></a></div>
+<p>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</p>
+</div>
+<h2>
+<a name="rfc.section.8.5">8.5</a>
+ How to I convert XSPF to Soundblox?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.5.p.1"></a></div>
+<p>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</p>
+</div>
+<h2>
+<a name="rfc.section.8.6">8.6</a>
+ How do I customize XSPF? Should I use namespaces?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.6.p.1"></a></div>
+<p>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</p>
+</div>
+<h2>
+<a name="rfc.section.8.7">8.7</a>
+ How do I validate XSPF?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.7.p.1"></a></div>
+<p>Matthias Friedrich has created an XML schema for XSPF
+ version 1 at <a href="http://www.stud.uni-karlsruhe.de/~uy7l/xspf-1.xsd">http://www.stud.uni-karlsruhe.de/~uy7l/xspf-1.xsd</a>.</p>
+<div><a name="rfc.section.8.7.p.2"></a></div>
+<p>Robert Kaye has created a Relax NG schema for XSPF
+ version 0 draft 8 at <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">http://mayhem-chaos.net/stuff/xspf-draft8.rng</a>.
+ You can use <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a>
+ to invoke it.</p>
+<div><a name="rfc.section.8.7.p.3"></a></div>
+<p>For users of Emacs nxml-mode, Ryan Shaw has posted a
+ .rnc version of Robert's schema at <a href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html">http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html</a>.
+ This is just a matter of putting the .rnc file in the
+ schema/ subdirectory of your nxml-mode installation.
+ nxml-mode will find it automatically and add it to the
+ list of available schemas; if you begin authoring an
+ XSPF playlist, nxml-mode will choose the correct schema
+ by examining the root element name.</p>
+</div>
+<h2>
+<a name="rfc.section.8.8">8.8</a>
+ How do I use MusicBrainz metadata?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.8.p.1"></a></div>
+<p>
+ Rather than include the literal artist name, song
+ duration, etc, for a track within a playlist,
+ MusicBrainz gives the URL of an XML file containing
+ these items. Assume that the MusicBrainz definition of
+ what a track listing means is at
+ http://musicbrainz.org/track. (There is nothing at that
+ URL, which is fine -- the URL in an XSPF meta[@rel]
+ attribute works the same way as the URL in an XML
+ namespace declaration). A typical track listing has a
+ URL like
+ http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429.</p>
+<div><a name="rfc.figure.u.11"></a></div>
+ <pre><track>
+ <identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+ <title>Smoke Two Joints</title>
+ <creator>Sublime</creator>
+ <duration>175466</duration>
+ <meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+
+</pre>
+ </div>
+<h2>
+<a name="rfc.section.8.9">8.9</a>
+ How do I refer to a BitTorrent?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.9.p.1"></a></div>
+<p>Put the torrent file in a playlist/trackList/track/location element.</p>
+</div>
+<h2>
+<a name="rfc.section.8.10">8.10</a>
+ How do I refer to a Magnet or sha1: URI?</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.8.10.p.1"></a></div>
+<p>A sha1: URI is a location independent canonical ID, so it
+ belongs in a playlist/trackList/track/identifier element. A
+ Magnet URI is resolvable, so belongs in
+ playlist/trackList/track/location.</p>
+</div>
+</div>
+ <hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1><a name="rfc.references">References</a></h1>
+<table summary="References" border="0">
+
+
+<tr>
+<td class="topnowrap"><b><a name="RFC2119">[RFC2119]</a></b></td>
+<td class="top">
+<a href="mailto:sob at harvard.edu" title="Harvard University">Bradner, S.</a>, "<a href="http://www.ietf.org/rfc/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td>
+</tr>
+</table>
+<hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.authors"></a>Author's Addresses</h1>
+<table summary="Authors" width="99%" border="0" cellpadding="0" cellspacing="0">
+<tr>
+<td> </td>
+<td>Lucas Gonze</td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td class="right"><b>EMail: </b></td>
+<td><a href="mailto:lucas at gonze.com">lucas at gonze.com</a></td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td> </td>
+<td>Matthias Friedrich</td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td class="right"><b>EMail: </b></td>
+<td><a href="mailto:matt at mafr.de">matt at mafr.de</a></td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td> </td>
+<td>Robert Kaye</td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td class="right"><b>EMail: </b></td>
+<td><a href="mailto:rob at eorbit.net">rob at eorbit.net</a></td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td> </td>
+<td>Dave Brown</td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+<tr>
+<td class="right"><b>EMail: </b></td>
+<td><a href="mailto:dabrown at yahoo-inc.com">dabrown at yahoo-inc.com</a></td>
+</tr>
+<tr>
+<td> </td>
+<td></td>
+</tr>
+</table>
+<hr class="noprint">
+<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;"><tr><td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2"> TOC </b></a></td></tr></table>
+<h1>
+<a name="rfc.section.A">A</a>
+ IANA Considerations</h1>
+<div style="margin-left: 8px;">
+<h2>
+<a name="rfc.section.A.1">A.1</a>
+ MIME media type name</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.1.p.1"></a></div>
+<p>application</p>
+</div>
+<h2>
+<a name="rfc.section.A.2">A.2</a>
+ MIME subtype name</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.2.p.1"></a></div>
+<p>xspf+xml</p>
+<div><a name="rfc.section.A.2.p.2"></a></div>
+<p>(This name is provisional, meaning that we have not yet
+ found a volunteer to steer it through the name-granting
+ process).</p>
+</div>
+<h2>
+<a name="rfc.section.A.3">A.3</a>
+ Mandatory parameters</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.3.p.1"></a></div>
+<p>none</p>
+</div>
+<h2>
+<a name="rfc.section.A.4">A.4</a>
+ Optional parameters</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.4.p.1"></a></div>
+<p>"charset", per <a href="#http://www.ietf.org/rfc/rfc3023.txt">RFC3023</a>.</p>
+</div>
+<h2>
+<a name="rfc.section.A.5">A.5</a>
+ Translated into plain english</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.5.p.1"></a></div>
+<p>The mime type for XSPF playlists is <code>application/xspf+xml</code>.</p>
+</div>
+<h2>
+<a name="rfc.section.A.6">A.6</a>
+ File extension</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.6.p.1"></a></div>
+<p>.xspf</p>
+</div>
+<h2>
+<a name="rfc.section.A.7">A.7</a>
+ Security Considerations</h2>
+<div style="margin-left: 8px;">
+<div><a name="rfc.section.A.7.p.1"></a></div>
+<p>Playlist authors should not publish documents containing local paths.</p>
+</div>
+</div>
+</body>
+</html>
More information about the commits
mailing list