[xiph-commits] r9875 - websites/xspf.org
lgonze at svn.xiph.org
lgonze at svn.xiph.org
Tue Aug 30 17:56:07 PDT 2005
Author: lgonze
Date: 2005-08-30 17:56:00 -0700 (Tue, 30 Aug 2005)
New Revision: 9875
Modified:
websites/xspf.org/about.html
websites/xspf.org/apps.html
websites/xspf.org/index.html
websites/xspf.org/list.html
websites/xspf.org/schema.html
websites/xspf.org/specs.html
websites/xspf.org/xspf-v0.html
websites/xspf.org/xspf-v1.html
Log:
Validate and tidy HTML. Convert to XHTML strict.
Modified: websites/xspf.org/about.html
===================================================================
--- websites/xspf.org/about.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/about.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,68 +1,39 @@
-<html charset="UTF-8">
+<html charset="UTF-8" xmlns="http://www.w3.org/1999/xhtml">
<head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
</head>
<body>
-
<div id="container">
<div id="title"></div>
-
-<div id="menu">
-<a class="menuItem" href="index.html">home</a> |
-<a class="menuItem" href="specs.html">specs</a> |
-<a class="menuItem" href="schema.html">schema</a> |
-<a class="menuItem" href="apps.html">applications</a> |
-<a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> |
-<a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
-<span class="selectedMenuItem">about us</span>
-</div>
-
+<div id="menu"><a class="menuItem" href="index.html">home</a> | <a class="menuItem" href="specs.html">specs</a> | <a class="menuItem" href="schema.html">schema</a> | <a class="menuItem" href="apps.html">applications</a> | <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <span class="selectedMenuItem">about us</span></div>
<div class="main">
-
<h1>About Us</h1>
-
-<p>Our group did what it did because we wanted to bring playlist
-formats up to snuff. There was no standards organization and no
-commercial sponsorship.</p>
-
-<p>We 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.</p>
-
-<p>During the spring of 2005 we settled XSPF into a home at
-<a href="http://xiph.org">Xiph.org</a>, a non-profit organization of
-like-minded people working on audio/video formats like Ogg Vorbis,
-FLAC, and SPEEX.</p>
-
-<p>A key document prior to our starting work was Lucas Gonze's <a
-href="http://gonze.com/playlists/playlist-format-survey.html">Survey
-of playlist formats</a>, finalized in November 2003.</p>
-
+<p>Our group did what it did because we wanted to bring playlist formats up to snuff. There was no standards organization and no commercial sponsorship.</p>
+<p>We 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.</p>
+<p>During the spring of 2005 we settled XSPF into a home at <a href="http://xiph.org">Xiph.org</a>, a non-profit organization of like-minded people working on audio/video formats like Ogg Vorbis, FLAC, and SPEEX.</p>
+<p>A key document prior to our starting work was Lucas Gonze's <a href="http://gonze.com/playlists/playlist-format-survey.html">Survey of playlist formats</a>, finalized in November 2003.</p>
<h2>Contributors to XSPF</h2>
-
<ul>
- <li>Lucas Gonze</li>
- <li>Matthias Friedrich</li>
- <li>Robert Kaye</li>
- <li>Dave Brown</li>
- <li>Dan Brickley</li>
- <li>Kevin Marks</li>
- <li>Ian C. Rogers</li>
- <li>Ryan Shaw</li>
- <li>Alf Eaton</li>
- <li>Steve Gedikian</li>
- <li>Russell Garrett</li>
- <li>Ben Tesch</li>
- <li>Tomas Franzén</li>
- <li>Jim Garrison</li>
- <li>Brander Lien</li>
- <li>Fabricio Zuardi</li>
+<li>Lucas Gonze</li>
+<li>Matthias Friedrich</li>
+<li>Robert Kaye</li>
+<li>Dave Brown</li>
+<li>Dan Brickley</li>
+<li>Kevin Marks</li>
+<li>Ian C. Rogers</li>
+<li>Ryan Shaw</li>
+<li>Alf Eaton</li>
+<li>Steve Gedikian</li>
+<li>Russell Garrett</li>
+<li>Ben Tesch</li>
+<li>Tomas Franzén</li>
+<li>Jim Garrison</li>
+<li>Brander Lien</li>
+<li>Fabricio Zuardi</li>
</ul>
-
</div>
</div>
-
</body>
</html>
Modified: websites/xspf.org/apps.html
===================================================================
--- websites/xspf.org/apps.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/apps.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,95 +1,45 @@
-<html>
- <head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
- </head>
- <body>
-
- <div id="container">
- <div id="title"></div>
-
- <div id="menu">
- <a class="menuItem" href="index.html">home</a> |
- <a class="menuItem" href="specs.html">specs</a> |
- <a class="menuItem" href="schema.html">schema</a> |
- <span class="selectedMenuItem">applications</span> |
- <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> |
- <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
- <a class="menuItem" href="about.html">about us</a>
- </div>
-
- <div class="main">
-
- <h1>Applications</h1>
-
- <dl>
-
- <dt><a href="http://gnomoradio.org/">Gnomoradio</a> (GNU/Linux)</dt>
- <dd>A program that can find, fetch, share, and play music that
- is freely available for file sharing.</dd>
-
- <dt><a href="http://webjay.org">Webjay</a> (web)</dt>
- <dd>A playlist community site and playlist authoring tool which
- exports XSPF playlists.</dd>
-
- <dt><a href="http://mayhem-chaos.net/stuff/xspf-download-0.1.0.py">xspf-download-0.1.0.py</a> (GNU/Linux)</dt>
- <dd>A Python script that parses XSPF and M3U files and downloads the
- files to the local harddrive.</dd>
-
- <dt><a href="http://musicplayer.sourceforge.net/">Musicplayer</a> (web)</dt>
- <dd>A popular Flash-based application for playing music in web
- pages. Open source under the BSD license; can be used and modified
- by anyone, including for commercial purposes.</dd>
-
- <dt><a href="http://playr.hubmed.org/">Playr</a> (web)</dt>
- <dd>A web-based tool for screen-scraping web pages and emitting the
- results as a playlist. Says Playr creator Alf Eaton:
-
- <cite>There's a Flash/XSPF bookmarklet on the front page --
- which you can use to directly play any page containing linked
- MP3s -- as well as 'Flash' links on the New Playlists page.
- </cite>
- </dd>
-
- <dt><a href="http://jinzora.com">Jinzora</a> (web)</dt>
- <dd>A web based media streaming and management system,
- designed to stream audio and video files to any internet
- connected computer.</dd>
-
- <dt><a href="http://music.yahoo.com/musicengine/">Yahoo! Music Engine</a> (Windows)</dt>
- <dd>The Windows-based client software for Yahoo! Music,
- which uses XSPF as its native playlist format. Says
- Yahoo's Ian Rogers: <cite>We're trying to push forward an
- OPEN standard for playlisting, because it's ridiculous
- that it's 2005 and we're lacking even the basic currency
- for media exchange due to more than a decade of
- short-sighted proprietary verticals by media and software
- companies.</cite></dd>
-
- <dt><a href="http://s1x.homelinux.net/projects/serpentine/">Serpentine</a> (GNU/Linux)</dt>
- <dd>Software for mastering audio CDs. It uses XSPF playlists to set the CD content.</dd>
-
- <dt><a href="http://plurn.com/app/About/">Plurn</a> (web)</dt>
- <dd>A web-based playlist community modeled after Webjay.</dd>
-
- <dt><a href="http://www.draftlight.net/dnex/mp3player/free/">ultraPh0nZ FMP256</a> (web)</dt>
- <dd>A Flash application for playing music in web pages. Skinnable and slick.</dd>
-
- <dt><a href="http://plurn.com/app/Download">Spiffy</a> (Windows)</dt>
-
- <dd>A client application that downloads XSPF playlist
- content, effectively localizing the playlist. In an
- alpha state as of this writing (Jun 4, 2005), but
- potentially very useful when it grows up.</dd>
-
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
+</head>
+<body>
+<div id="container">
+<div id="title"></div>
+<div id="menu"><a class="menuItem" href="index.html">home</a> | <a class="menuItem" href="specs.html">specs</a> | <a class="menuItem" href="schema.html">schema</a> | <span class="selectedMenuItem">applications</span> | <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <a class="menuItem" href="about.html">about us</a></div>
+<div class="main">
+<h1>Applications</h1>
+<dl>
+<dt><a href="http://gnomoradio.org/">Gnomoradio</a> (GNU/Linux)</dt>
+<dd>A program that can find, fetch, share, and play music that is freely available for file sharing.</dd>
+<dt><a href="http://webjay.org">Webjay</a> (web)</dt>
+<dd>A playlist community site and playlist authoring tool which exports XSPF playlists.</dd>
+<dt><a href="http://mayhem-chaos.net/stuff/xspf-download-0.1.0.py">xspf-download-0.1.0.py</a> (GNU/Linux)</dt>
+<dd>A Python script that parses XSPF and M3U files and downloads the files to the local harddrive.</dd>
+<dt><a href="http://musicplayer.sourceforge.net/">Musicplayer</a> (web)</dt>
+<dd>A popular Flash-based application for playing music in web pages. Open source under the BSD license; can be used and modified by anyone, including for commercial purposes.</dd>
+<dt><a href="http://playr.hubmed.org/">Playr</a> (web)</dt>
+<dd>A web-based tool for screen-scraping web pages and emitting the results as a playlist. Says Playr creator Alf Eaton: <cite>There's a Flash/XSPF bookmarklet on the front page -- which you can use to directly play any page containing linked MP3s -- as well as 'Flash' links on the New Playlists page.</cite></dd>
+<dt><a href="http://jinzora.com">Jinzora</a> (web)</dt>
+<dd>A web based media streaming and management system, designed to stream audio and video files to any internet connected computer.</dd>
+<dt><a href="http://music.yahoo.com/musicengine/">Yahoo! Music Engine</a> (Windows)</dt>
+<dd>The Windows-based client software for Yahoo! Music, which uses XSPF as its native playlist format. Says Yahoo's Ian Rogers: <cite>We're trying to push forward an OPEN standard for playlisting, because it's ridiculous that it's 2005 and we're lacking even the basic currency for media exchange due to more than a decade of short-sighted proprietary verticals by media and software companies.</cite></dd>
+<dt><a href="http://s1x.homelinux.net/projects/serpentine/">Serpentine</a> (GNU/Linux)</dt>
+<dd>Software for mastering audio CDs. It uses XSPF playlists to set the CD content.</dd>
+<dt><a href="http://plurn.com/app/About/">Plurn</a> (web)</dt>
+<dd>A web-based playlist community modeled after Webjay.</dd>
+<dt><a href="http://www.draftlight.net/dnex/mp3player/free/">ultraPh0nZ FMP256</a> (web)</dt>
+<dd>A Flash application for playing music in web pages. Skinnable and slick.</dd>
+<dt><a href="http://plurn.com/app/Download">Spiffy</a> (Windows)</dt>
+<dd>A client application that downloads XSPF playlist content, effectively localizing the playlist. In an alpha state as of this writing (Jun 4, 2005), but potentially very useful when it grows up.</dd>
<!-- template for new entries
- <dt><a href=""></a></dt>
- <dd></dd>
--->
-
- </dl>
-
- </div>
- </div>
- </body>
+ <dt><a href=""></a></dt>
+ <dd></dd>
+--></dl>
+</div>
+</div>
+</body>
</html>
Modified: websites/xspf.org/index.html
===================================================================
--- websites/xspf.org/index.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/index.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,50 +1,32 @@
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
</head>
<body>
-
<div id="container">
<div id="title"></div>
-
-<div id="menu">
-<span class="selectedMenuItem">home</span> |
-<a class="menuItem" href="specs.html">specs</a> |
-<a class="menuItem" href="schema.html">schema</a> |
-<a class="menuItem" href="apps.html">applications</a> |
-<a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> |
-<a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
-<a class="menuItem" href="about.html">about us</a>
-</div>
-
+<div id="menu"><span class="selectedMenuItem">home</span> | <a class="menuItem" href="specs.html">specs</a> | <a class="menuItem" href="schema.html">schema</a> | <a class="menuItem" href="apps.html">applications</a> | <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <a class="menuItem" href="about.html">about us</a></div>
<div class="main">
-
<h1>XML Shareable Playlist Format ("spiff")</h1>
-
<p>XSPF is the XML format for sharing playlists.</p>
-
<ul>
-<li>It is <em>open</em> -- No proprietary lock-in. </a>
-<li>It is <em>portable</em> -- You should be able to send a playlist to your friend and have it work.</a>
+<li>It is <em>open</em> -- No proprietary lock-in.</li>
+<li>It is <em>portable</em> -- You should be able to send a playlist to your friend and have it work.</li>
<li>It is <em>well-engineered</em> -- Most playlist formats get the easy things wrong.</li>
</ul>
-
<dl>
- <dt>Unlike M3U</dt>
- <dd>XSPF is XML.</dd>
-
- <dt>Unlike SMIL</dt>
- <dd>XSPF is simple.</dd>
-
- <dt>Unlike ASX</dt>
- <dd>XSPF is open.</dd>
+<dt>Unlike M3U</dt>
+<dd>XSPF is XML.</dd>
+<dt>Unlike SMIL</dt>
+<dd>XSPF is simple.</dd>
+<dt>Unlike ASX</dt>
+<dd>XSPF is open.</dd>
</dl>
-
-
-
</div>
</div>
-
</body>
</html>
Modified: websites/xspf.org/list.html
===================================================================
--- websites/xspf.org/list.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/list.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,33 +1,19 @@
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
</head>
<body>
-
<div id="container">
<div id="title"></div>
-
-<div id="menu">
-<a class="menuItem" href="index.html">home</a> |
-<a class="menuItem" href="specs.html">specs</a> |
-<a class="menuItem" href="schema.html">schema</a> |
-<a class="menuItem" href="apps.html">applications</a> |
-<span class="selectedMenuItem">mailing list</span> |
-<a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
-<a class="menuItem" href="about.html">about us</a>
-</div>
-
+<div id="menu"><a class="menuItem" href="index.html">home</a> | <a class="menuItem" href="specs.html">specs</a> | <a class="menuItem" href="schema.html">schema</a> | <a class="menuItem" href="apps.html">applications</a> | <span class="selectedMenuItem">mailing list</span> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <a class="menuItem" href="about.html">about us</a></div>
<div class="main">
-
<h1>Mailing List</h1>
-
-<p>
-The <a href="http://lists.musicbrainz.org/mailman/listinfo/playlist">playlist mailing list</a> is dedicated to discussing any and all issues relating to XSPF. This mailing list also has an <a href="http://lists.musicbrainz.org/pipermail/playlist/">archive</a>.
-</p>
-
+<p>The <a href="http://lists.musicbrainz.org/mailman/listinfo/playlist">playlist mailing list</a> is dedicated to discussing any and all issues relating to XSPF. This mailing list also has an <a href="http://lists.musicbrainz.org/pipermail/playlist/">archive</a>.</p>
</div>
</div>
-
</body>
</html>
Modified: websites/xspf.org/schema.html
===================================================================
--- websites/xspf.org/schema.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/schema.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,63 +1,26 @@
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
</head>
<body>
-
<div id="container">
<div id="title"></div>
-
-<div id="menu">
-<a class="menuItem" href="index.html">home</a> |
-<a class="menuItem" href="specs.html">specs</a> |
-<span class="selectedMenuItem">schema</span> |
-<a class="menuItem" href="apps.html">applications</a> |
-<a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> |
-<a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
-<a class="menuItem" href="about.html">about us</a>
-</div>
-
+<div id="menu"><a class="menuItem" href="index.html">home</a> | <a class="menuItem" href="specs.html">specs</a> | <span class="selectedMenuItem">schema</span> | <a class="menuItem" href="apps.html">applications</a> | <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <a class="menuItem" href="about.html">about us</a></div>
<div class="main">
-
<h1>Schema</h1>
-
-<p>
-XSPF provides a schema definition file that uses <a href="http://relaxng.org">Relax NG</a>.
-</p>
-
-<p>
-The latest schema file is <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">xspf-draft8.rng</a>,
-and the example playlist to go with that is
-<a href="http://mayhem-chaos.net/stuff/playlist.xml">playlist.xml</a>.
-</p>
-
-<p>
-Please note that the schema definition does not match draft 8 completely. There are some notes at
-the top of the schema that outlines problems with respect to draft 8. Hopefully we can come up with draft 9
-soon and write a schema that actually matches it. :-)
-</p>
-
+<p>XSPF provides a schema definition file that uses <a href="http://relaxng.org">Relax NG</a>.</p>
+<p>The latest schema file is <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">xspf-draft8.rng</a>, and the example playlist to go with that is <a href="http://mayhem-chaos.net/stuff/playlist.xml">playlist.xml</a>.</p>
+<p>Please note that the schema definition does not match draft 8 completely. There are some notes at the top of the schema that outlines problems with respect to draft 8. Hopefully we can come up with draft 9 soon and write a schema that actually matches it. :-)</p>
<h1>Schema with extension support</h1>
-
-<p>
-This schema allows for namespace extensions to be added and still have the document validate correctly: <a href="http://mayhem-chaos.net/stuff/xspf-draft-8-ext.rng">xspf-draft-8-ext.rng</a>,
-and the example playlist to go with that is
-<a href="http://mayhem-chaos.net/stuff/playlist-ext.xml">playlist-ext.xml</a>.
-</p>
-
-<p>
-For an explanation of this schema, please see this <a href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000439.html">mailing list post</a>.
-</p>
-
+<p>This schema allows for namespace extensions to be added and still have the document validate correctly: <a href="http://mayhem-chaos.net/stuff/xspf-draft-8-ext.rng">xspf-draft-8-ext.rng</a>, and the example playlist to go with that is <a href="http://mayhem-chaos.net/stuff/playlist-ext.xml">playlist-ext.xml</a>.</p>
+<p>For an explanation of this schema, please see this <a href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000439.html">mailing list post</a>.</p>
<h1>Validation</h1>
-
-<p>
-To validate your XSPF playlists with the above schemas, we suggest using <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a>.
-</p>
-
+<p>To validate your XSPF playlists with the above schemas, we suggest using <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a>.</p>
</div>
</div>
-
</body>
</html>
Modified: websites/xspf.org/specs.html
===================================================================
--- websites/xspf.org/specs.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/specs.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,53 +1,32 @@
-<html>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
<head>
- <title>XML Shareable Playlist Format</title>
- <link rel="stylesheet" href="css/main.css" type="text/css" />
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<title>XML Shareable Playlist Format</title>
+<link rel="stylesheet" href="css/main.css" type="text/css" />
</head>
<body>
-
<div id="container">
<div id="title"></div>
-
-<div id="menu">
-<a class="selected" href="index.html">home</a> |
-<span class="selectedMenuItem">specs</span> |
-<a class="menuItem" href="schema.html">schema</a> |
-<a class="menuItem" href="apps.html">applications</a> |
-<a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> |
-<a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> |
-<a class="menuItem" href="about.html">about us</a>
-</div>
-
+<div id="menu"><a class="selected" href="index.html">home</a> | <span class="selectedMenuItem">specs</span> | <a class="menuItem" href="schema.html">schema</a> | <a class="menuItem" href="apps.html">applications</a> | <a class="menuItem" href="http://lists.musicbrainz.org/mailman/listinfo/playlist">mailing list</a> | <a class="menuItem" href="http://wiki.xiph.org/index.php/XSPF">developer wiki</a> | <a class="menuItem" href="about.html">about us</a></div>
<div class="main">
-
<h1>Specifications</h1>
-
-<p>XSPF version 0 was finished and frozen in late April 2004. XSPF
-version 1 was finished and frozen in March 2005. The differences
-between them are subtle and fairly minor, so <em>please use version 1</em>
-unless you have a compelling reason not to.</p>
-
+<p>XSPF version 0 was finished and frozen in late April 2004. XSPF version 1 was finished and frozen in March 2005. The differences between them are subtle and fairly minor, so <em>please use version 1</em> unless you have a compelling reason not to.</p>
<ul>
- <li><a href="xspf-v0.html">Specification for XSPF version 0</a></li>
- <li><a href="xspf-v1.html">Specification for XSPF version 1</a> (recommended)</li>
+<li><a href="xspf-v0.html">Specification for XSPF version 0</a></li>
+<li><a href="xspf-v1.html">Specification for XSPF version 1</a> (recommended)</li>
</ul>
-
<h2>Differences between version 0 and version 1</h2>
-
<ul>
- <li><code>trackList</code> may be empty.</li>
- <li><code>extension</code> added.</li>
- <li><code>date</code> changed from ISO 8601 to xsd:dateTime.</li>
- <li><code>version</code> incremented.</li>
+<li><code>trackList</code> may be empty.</li>
+<li><code>extension</code> added.</li>
+<li><code>date</code> changed from ISO 8601 to xsd:dateTime.</li>
+<li><code>version</code> incremented.</li>
</ul>
-
<h2>Mime type</h2>
-
-<div>The mime type for XSPF playlists is <code>application/xspf+xml</code>.
+<div>The mime type for XSPF playlists is <code>application/xspf+xml</code>.</div>
</div>
-
</div>
-</div>
-
</body>
</html>
Modified: websites/xspf.org/xspf-v0.html
===================================================================
--- websites/xspf.org/xspf-v0.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/xspf-v0.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,10 +1,12 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+ "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">
+<head>
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
+<title>The XSPF Playlist Format, version 0</title>
+
+<style type="text/css">
/*<![CDATA[*/
body {
@@ -52,45 +54,19 @@
/*]]>*/
- </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>
+</style>
+</head>
+<body>
+<h1>The XSPF Playlist Format, version 0</h1>
+<a name="WhatisXSPF" id="WhatisXSPF"></a>
+<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" id="Example"></a>
+<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>
@@ -100,10 +76,10 @@
<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>
-
+</playlist>
+</pre>
or this:
- <pre>
+<pre>
<?xml version="1.0" encoding="UTF-8"?>
<playlist version="0" xmlns = "http://xspf.org/ns/0/">
<trackList>
@@ -113,34 +89,43 @@
<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>
+</playlist>
+</pre>
+<a name="toc" id="toc"></a>
+<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>
+<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>
+</ol>
+</li>
<li><a href="#Elementdefinitions">Element definitions</a></li>
-<li ><ol>
+<li>
+<ol>
<li><a href="#xml">xml</a></li>
-<li class="attributes"><ol>
+<li class="attributes">
+<ol>
<li><a href="#version">version</a></li>
<li><a href="#encoding">encoding</a></li>
-</ol></li>
-<li class="elements"><ol>
+</ol>
+</li>
+<li class="elements">
+<ol>
<li><a href="#playlist">playlist</a></li>
-<li class="attributes"><ol>
+<li class="attributes">
+<ol>
<li><a href="#xmlns">xmlns</a></li>
<li><a href="#version">version</a></li>
-</ol></li>
-<li class="elements"><ol>
+</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>
@@ -152,17 +137,23 @@
<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 class="attributes">
+<ol>
<li><a href="#rel">rel</a></li>
-</ol></li>
+</ol>
+</li>
<li><a href="#meta">meta</a></li>
-<li class="attributes"><ol>
+<li class="attributes">
+<ol>
<li><a href="#rel">rel</a></li>
-</ol></li>
+</ol>
+</li>
<li><a href="#trackList">trackList</a></li>
-<li class="elements"><ol>
+<li class="elements">
+<ol>
<li><a href="#track">track</a></li>
-<li class="elements"><ol>
+<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>
@@ -174,30 +165,44 @@
<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 class="attributes">
+<ol>
<li><a href="#rel">rel</a></li>
-</ol></li>
+</ol>
+</li>
<li><a href="#meta">meta</a></li>
-<li class="attributes"><ol>
+<li class="attributes">
+<ol>
<li><a href="#rel">rel</a></li>
-</ol></li>
-</ol></li>
-</ol></li>
-</ol></li>
-</ol></li>
-</ol></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>
+<ol>
<li><a href="#Contentresolver">Content resolver</a></li>
<li><a href="#Fuzzynames">Fuzzy names</a></li>
-</ol></li>
+</ol>
+</li>
<li><a href="#RequirementsforXSPFplayers">Requirements for XSPF players</a></li>
-<li ><ol>
+<li>
+<ol>
<li><a href="#Gracefulfailure">Graceful failure</a></li>
<li><a href="#Relativepaths">Relative paths</a></li>
-</ol></li>
+</ol>
+</li>
<li><a href="#Usecasesforplaylists">Usecases for playlists</a></li>
-<li ><ol>
+<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>
@@ -205,706 +210,342 @@
<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>
+</ol>
+</li>
<li><a href="#Recipes">Recipes</a></li>
-<li ><ol>
+<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="#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>
+</ol>
+</li>
<li><a href="#Administrative">Administrative</a></li>
-<li ><ol>
+<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>
+</ol>
+</li>
+</ol>
+<a name="Administrativenotes" id="Administrativenotes"></a>
+<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" id="Abstractions"></a>
+<h2>Abstractions</h2>
+<dl>
+<dt><a name="Definingplaylists" id="Definingplaylists"></a>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" id="Whataplaylistisnot"></a>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" id="Shareability"></a>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" id="Elementdefinitions"></a>
+<h2>Element definitions</h2>
+<dl>
+<dt><a name="xml" id="xml"></a>xml</dt>
+<dd>
+<dl class="attributes">
+<dt><a name="version" id="version"></a>version</dt>
+<dd>1.0</dd>
+<dt><a name="encoding" id="encoding"></a>encoding</dt>
+<dd>utf-8 recommended to allow unicode characters in text fields</dd>
+</dl>
+<dl class="elements">
+<dt><a name="playlist" id="playlist"></a>playlist</dt>
+<dd>
+<dl class="attributes">
+<dt><a name="xmlns" id="xmlns"></a>xmlns</dt>
+<dd>http://xspf.org/ns/0/</dd>
+<dt><a name="version" id="version"></a>version</dt>
+<dd>0</dd>
+</dl>
+<dl class="elements">
+<dt><a name="title" id="title"></a>title</dt>
+<dd>A human-readable title for the playlist. xspf:playlist elements MAY contain exactly one.</dd>
+<dt><a name="annotation" id="annotation"></a>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" id="creator"></a>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" id="info"></a>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" id="location"></a>location</dt>
+<dd>Source URI for this playlist. xspf:playlist elements MAY contain zero or more location elements.</dd>
+<dt><a name="identifier" id="identifier"></a>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" id="image"></a>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" id="date"></a>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" id="license"></a>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" id="attribution"></a>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>
+ </attribution>
+</pre></dd>
+<dt><a name="link" id="link"></a>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" id="rel"></a>rel</dt>
+<dd>URI of a resource type.</dd>
+</dl>
+<p>URI of a resource.</p>
+</dd>
+<dt><a name="meta" id="meta"></a>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" id="rel"></a>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" id="trackList"></a>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" id="track"></a>track</dt>
+<dd>
+<dl class="elements">
+<dt><a name="location" id="location"></a>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" id="identifier"></a>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" id="title"></a>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" id="annotation"></a>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" id="creator"></a>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" id="info"></a>info</dt>
+<dd>URI of a place where this resource can be bought or more info can be found.</dd>
+<dt><a name="image" id="image"></a>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" id="album"></a>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" id="trackNum"></a>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" id="duration"></a>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" id="link"></a>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" id="rel"></a>rel</dt>
+<dd>URI of a resource type.</dd>
+</dl>
+<p>URI of a resource.</p>
+</dd>
+<dt><a name="meta" id="meta"></a>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" id="rel"></a>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" id="Designandarchitecture"></a>
+<h2>Design and architecture</h2>
+<dl>
+<dt><a name="Contentresolver" id="Contentresolver"></a>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" id="Fuzzynames"></a>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" id="RequirementsforXSPFplayers"></a>
+<h2>Requirements for XSPF players</h2>
+<dl><!-- begin requirements -->
+<dt><a name="Gracefulfailure" id="Gracefulfailure"></a>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>
+</dd>
+<dt><a name="Relativepaths" id="Relativepaths"></a>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" id="Usecasesforplaylists"></a>
+<h2>Usecases for playlists</h2>
+<dl>
+<dt><a name="Flagplayerapplication" id="Flagplayerapplication"></a>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" id="Allowstreaming"></a>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" id="Collectingfragmentedresources"></a>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" id="Alternatemediatypes"></a>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" id="Cachingderivedinfo"></a>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" id="Metadatastorage"></a>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" id="Authoringcompilationsforexpressivereasons"></a>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" id="Recipes"></a>
+<h2>Recipes</h2>
+<dl>
+<dt><a name="HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest" id="HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest"></a>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" id="HowtoIconvertXSPFtoM3U"></a>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" id="HowtoIconvertXSPFtoHTML"></a>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" id="HowtoIconvertXSPFtoSMIL"></a>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" id="HowtoIconvertXSPFtoSoundblox"></a>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" id="HowdoIcustomizeXSPFShouldIusenamespaces"></a>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" id="HowdoIvalidateXSPF"></a>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" id="HowdoIuseMusicBrainzmetadata"></a>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" id="HowdoIrefertoaBitTorrent"></a>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" id="HowdoIrefertoaMagnetorsha1URI"></a>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" id="Administrative"></a>
+<h2>Administrative</h2>
+<dl>
+<dt><a name="Validate" id="Validate"></a>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>
Modified: websites/xspf.org/xspf-v1.html
===================================================================
--- websites/xspf.org/xspf-v1.html 2005-08-31 00:28:00 UTC (rev 9874)
+++ websites/xspf.org/xspf-v1.html 2005-08-31 00:56:00 UTC (rev 9875)
@@ -1,9 +1,13 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
-<html lang="en-US">
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html lang="en-US" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
<head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+<meta name="generator" content="HTML Tidy for Cygwin (vers 1st September 2004), see www.w3.org" />
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>XSPF Version 1</title>
+
<style type="text/css">
+/*<![CDATA[*/
a
{
text-decoration: none
@@ -180,26 +184,31 @@
@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">
+<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>
+<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>
@@ -211,15 +220,11 @@
<td class="header">M. Friedrich</td>
</tr>
<tr>
-<td class="header">
- <xspf-v1-draft1>
- </td>
+<td class="header"><xspf-v1-draft1></td>
<td class="header">R. Kaye</td>
</tr>
<tr>
-<td class="header">
- Category:
- Informational</td>
+<td class="header">Category: Informational</td>
<td class="header">D. Brown</td>
</tr>
<tr>
@@ -227,1402 +232,561 @@
<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>
+<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">
+<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>
+<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>
+<h1><a name="rfc.toc" id="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" id="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><a name="rfc.section.1.p.1" id="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" id="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" id="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" id="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/">
+<div><a name="rfc.figure.u.1" id="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/">
+<div><a name="rfc.figure.u.2" id="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>
+
+</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>
+<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" id="rfc.section.2">2</a> Administration</h1>
<div style="margin-left: 8px;">
-<h2>
-<a name="rfc.section.2.1">2.1</a>
- History</h2>
+<h2><a name="rfc.section.2.1" id="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><a name="rfc.section.2.1.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.2.2" id="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><a name="rfc.section.2.2.p.1" id="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>
+<h2><a name="rfc.section.2.3" id="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>
+<h3><a name="rfc.section.2.3.1" id="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><a name="rfc.section.2.3.1.p.1" id="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" id="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>
+<h3><a name="rfc.section.2.3.2" id="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><a name="rfc.section.2.3.2.p.1" id="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>
+<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" id="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>
+<h2><a name="rfc.section.3.1" id="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><a name="rfc.section.3.1.p.1" id="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>
+<h2><a name="rfc.section.3.2" id="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><a name="rfc.section.3.2.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.3.3" id="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><a name="rfc.section.3.3.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.3.4" id="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><a name="rfc.section.3.4.p.1" id="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" id="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" id="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" id="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>
+<h2><a name="rfc.section.3.5" id="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><a name="rfc.section.3.5.p.1" id="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>
+<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" id="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>
+<h2><a name="rfc.section.4.1" id="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>
+<h3><a name="rfc.section.4.1.1" id="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>
+<h3><a name="rfc.section.4.1.1.1" id="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>
+<h3><a name="rfc.section.4.1.1.1.1" id="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>
+<div><a name="rfc.section.4.1.1.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.1.2" id="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>
+<div><a name="rfc.section.4.1.1.1.2.p.1" id="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><a name="rfc.section.4.1.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2" id="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>
+<h3><a name="rfc.section.4.1.1.2.1" id="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><a name="rfc.section.4.1.1.2.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.2" id="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><a name="rfc.section.4.1.1.2.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.3" id="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><a name="rfc.section.4.1.1.2.3.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.4" id="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><a name="rfc.section.4.1.1.2.4.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.5" id="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><a name="rfc.section.4.1.1.2.5.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.6" id="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><a name="rfc.section.4.1.1.2.6.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.7" id="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><a name="rfc.section.4.1.1.2.7.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.8" id="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);
+<div><a name="rfc.section.4.1.1.2.8.p.1" id="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" id="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><a name="rfc.section.4.1.1.2.8.p.3" id="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>
+<h3><a name="rfc.section.4.1.1.2.9" id="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><a name="rfc.section.4.1.1.2.9.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.10" id="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>
+<div><a name="rfc.section.4.1.1.2.10.p.1" id="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" id="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" id="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>
+</pre></div>
+<h3><a name="rfc.section.4.1.1.2.11" id="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>
-
+<div><a name="rfc.section.4.1.1.2.11.p.1" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.11.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.11.1.1" id="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>
+<div><a name="rfc.section.4.1.1.2.11.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.11.2" id="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>
+<div><a name="rfc.section.4.1.1.2.11.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.12" id="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>
-
+<div><a name="rfc.section.4.1.1.2.12.p.1" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.12.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.12.1.1" id="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>
+<div><a name="rfc.section.4.1.1.2.12.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.12.2" id="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><a name="rfc.section.4.1.1.2.12.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.13" id="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"/>
+<div><a name="rfc.section.4.1.1.2.13.p.1" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.13.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.13.1.1" id="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><a name="rfc.section.4.1.1.2.13.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.13.2" id="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>
+<div><a name="rfc.section.4.1.1.2.13.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14" id="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><a name="rfc.section.4.1.1.2.14.p.1" id="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" id="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" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.1" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.2" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.3" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.3.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.4" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.4.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.5" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.5.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.6" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.6.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.7" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.7.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.8" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.8.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.9" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.9.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.10" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.10.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.11" id="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>
-
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.p.1" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.11.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.11.1.1" id="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>
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.11.2" id="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>
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.11.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.12" id="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>
-
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.12.p.1" id="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" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.12.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.12.1.1" id="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>
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.12.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.12.2" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.12.2.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.13" id="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">
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.13.p.1" id="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" id="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 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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.13.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.13.1.1" id="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><a name="rfc.section.4.1.1.2.14.1.1.1.13.1.1.p.1" id="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>
+<h3><a name="rfc.section.4.1.1.2.14.1.1.1.13.2" id="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>
+<div><a name="rfc.section.4.1.1.2.14.1.1.1.13.2.p.1" id="rfc.section.4.1.1.2.14.1.1.1.13.2.p.1"></a></div>
<p>nested XML.</p>
</div>
</div>
@@ -1634,398 +798,215 @@
</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>
+<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" id="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><a name="rfc.section.5.p.1" id="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>
+<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" id="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>
+<h2><a name="rfc.section.6.1" id="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><a name="rfc.section.6.1.p.1" id="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>
+<h2><a name="rfc.section.6.2" id="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
+<div><a name="rfc.section.6.2.p.1" id="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).
+ 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>
+</pre></div>
+<h2><a name="rfc.section.6.3" id="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><a name="rfc.section.6.3.p.1" id="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>
+<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" id="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>
+<h2><a name="rfc.section.7.1" id="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><a name="rfc.section.7.1.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.2" id="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><a name="rfc.section.7.2.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.3" id="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><a name="rfc.section.7.3.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.4" id="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><a name="rfc.section.7.4.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.5" id="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><a name="rfc.section.7.5.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.6" id="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><a name="rfc.section.7.6.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.7.7" id="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><a name="rfc.section.7.7.p.1" id="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" id="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" id="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>
+<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" id="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>
+<h2><a name="rfc.section.8.1" id="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>
+<div><a name="rfc.section.8.1.p.1" id="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>
+<h2><a name="rfc.section.8.2" id="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>
+<div><a name="rfc.section.8.2.p.1" id="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>
+<h2><a name="rfc.section.8.3" id="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>
+<div><a name="rfc.section.8.3.p.1" id="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>
+<h2><a name="rfc.section.8.4" id="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>
+<div><a name="rfc.section.8.4.p.1" id="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>
+<h2><a name="rfc.section.8.5" id="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>
+<div><a name="rfc.section.8.5.p.1" id="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>
+<h2><a name="rfc.section.8.6" id="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><a name="rfc.section.8.6.p.1" id="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>
+<h2><a name="rfc.section.8.7" id="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><a name="rfc.section.8.7.p.1" id="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" id="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" id="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>
+<h2><a name="rfc.section.8.8" id="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>
+<div><a name="rfc.section.8.8.p.1" id="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" id="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>
+ <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>
+
+</pre></div>
+<h2><a name="rfc.section.8.9" id="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>
+<div><a name="rfc.section.8.9.p.1" id="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>
+<h2><a name="rfc.section.8.10" id="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><a name="rfc.section.8.10.p.1" id="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>
+<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" id="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>", BCP14, RFC2119, March1997.</td>
+<td class="topnowrap"><b><a name="RFC2119" id="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>", BCP14, RFC2119, March1997.</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>
+<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" id="rfc.authors"></a>Author's Addresses</h1>
<table summary="Authors" width="99%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td></td>
@@ -2092,63 +1073,49 @@
<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>
+<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" id="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>
+<h2><a name="rfc.section.A.1" id="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>
+<div><a name="rfc.section.A.1.p.1" id="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>
+<h2><a name="rfc.section.A.2" id="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>
+<div><a name="rfc.section.A.2.p.1" id="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><a name="rfc.section.A.2.p.2" id="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>
+<h2><a name="rfc.section.A.3" id="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>
+<div><a name="rfc.section.A.3.p.1" id="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>
+<h2><a name="rfc.section.A.4" id="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><a name="rfc.section.A.4.p.1" id="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>
+<h2><a name="rfc.section.A.5" id="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>
+<div><a name="rfc.section.A.5.p.1" id="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>
+<h2><a name="rfc.section.A.6" id="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>
+<div><a name="rfc.section.A.6.p.1" id="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>
+<h2><a name="rfc.section.A.7" id="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>
+<div><a name="rfc.section.A.7.p.1" id="rfc.section.A.7.p.1"></a></div>
<p>Playlist authors should not publish documents containing local paths.</p>
</div>
</div>
More information about the commits
mailing list