[xiph-commits] r12014 - websites/xspf.org
lgonze at svn.xiph.org
lgonze at svn.xiph.org
Sat Nov 4 17:44:27 PST 2006
Author: lgonze
Date: 2006-11-04 17:44:23 -0800 (Sat, 04 Nov 2006)
New Revision: 12014
Modified:
websites/xspf.org/draft-xspf-v1.html
Log:
MAJOR UPDATE
Commit Ivo Concalves rewrite of the HTML. This is a *large* update to do such things as convert tables to structural HTML.
Finally getting a copyright statement in there. Used Creative Commons Attribution-NoDerivs 2.5 License because it is so much less
cumbersome than the GFDL, and because the GFDL requires us to allow derivatives.
Improve explanation of link, meta and extension elements.
Check links and remove a couple broken internal links in the TOC.
Removed Dave Brown from authors list and added him to acknowledgements. It just seems patently false to claim that he contributed
to v1.
Updated acknowledgements section.
Deleted usecases section, which is mainly a source of bloat and potential errors and doesn't belong in a standards document.
Changed "2.3.2 Requirements notation" to say that [RFC2119] is the definition of MUST, SHOULD, etc. The old language was
confusing.
***I do not believe that any of these edits will invalidate any real world implementation of the specification.***
Modified: websites/xspf.org/draft-xspf-v1.html
===================================================================
--- websites/xspf.org/draft-xspf-v1.html 2006-11-05 01:42:03 UTC (rev 12013)
+++ websites/xspf.org/draft-xspf-v1.html 2006-11-05 01:44:23 UTC (rev 12014)
@@ -2,988 +2,704 @@
"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=utf-8" />
<title>XSPF Version 1</title>
<style type="text/css">
/*<![CDATA[*/
-a
-{
- text-decoration: none;
-}
-a:hover
-{
- text-decoration: underline;
-}
-a:active
-{
- text-decoration: underline;
-}
-body
-{
-
- color: #000000;
- font-family: helvetica, arial, sans-serif;
- font-size: 13px;
-}
-dl
-{
- margin-left: 2em;
-}
-h1
-{
- color: #333333;
- font-size: 16px;
- line-height: 16px;
- font-family: helvetica, arial, sans-serif;
- page-break-after: avoid;
-}
-h2
-{
- color: #000000;
- font-size: 14px;
- font-family: helvetica, arial, sans-serif;
- page-break-after: avoid;
-}
-h3
-{
- color: #000000;
- font-size: 13px;
- font-family: helvetica, arial, sans-serif;
- page-break-after: avoid;
-}
-li
-{
- margin-left: 2em;
- margin-right: 2em;
-}
-ol
-{
- margin-left: 2em;
- margin-right: 2em;
-}
-p
-{
- margin-left: 2em;
- margin-right: 2em;
-}
-pre
-{
- margin-left: 3em;
- background-color: lightyellow;
-}
-tt {
-font-face: courier;
-}
-table
-{
- margin-left: 2em;
- font-size: 13px;
-}
-td.top
-{
- vertical-align: top;
-}
-td.topnowrap
-{
- vertical-align: top;
- white-space: nowrap;
-}
-td.right
-{
- text-align: right;
-}
-td.header
-{
- width: 33%;
- color: #ffffff;
- background-color: #666666;
- font-size: 10px;
- font-family: arial, helvetica, sans-serif;
- vertical-align: top
-}
-.editingmark
-{
- background-color: khaki;
-}
-.hotText
-{
- color:#ffffff;
- font-weight: normal;
- text-decoration: none;
- font-family: helvetica, arial, sans-serif;
- font-size: 9px
-}
-.link2
-{
- color:#ffffff;
- font-weight: bold;
- text-decoration: none;
- font-family: helvetica, arial, sans-serif;
- font-size: 9px
-}
-.toowide
-{
- color: red;
- font-weight: bold;
-}
-.RFC
-{
- color:#666666;
- font-weight: bold;
- text-decoration: none;
- font-family: helvetica, arial, sans-serif;
- font-size: 9px
-}
-.title
-{
- color: #990000;
- font-size: 22px;
- line-height: 22px;
- font-weight: bold;
- text-align: right;
- font-family: helvetica, arial, sans-serif
-}
-.figure
-{
- font-weight: bold;
- text-align: center;
- font-size: 12px;
-}
-.filename
-{
- color: #333333;
- font-weight: bold;
- font-size: 16px;
- line-height: 24px;
- font-family: helvetica, arial, sans-serif;
- text-align: right;
-}
-
-del
-{
- color: red;
-}
-
-ins
-{
- color: blue;
-}
-table.resolution
-{
- background-color: khaki;
- border-width: thin;
- border-style: solid;
- border-color: black;
- margin-left: auto;
- margin-right: 0;
- float: right;
-}
-
- at media print {
- .noprint {display:none}
-}
-/*]]>*/
-</style>
-<link rel="Contents" href="#rfc.toc" />
-<link rel="Author" href="#rfc.authors" />
-<link rel="Copyright" href="#rfc.copyright" />
-<link rel="Chapter" title="1 Introduction" href="#rfc.section.1" />
-<link rel="Chapter" title="2 Administration" href="#rfc.section.2" />
-<link rel="Chapter" title="3 Abstractions" href="#rfc.section.3" />
-<link rel="Chapter" title="4 Element definitions" href="#rfc.section.4" />
-<link rel="Chapter" title="5 Requirements for XSPF generators" href="#rfc.section.5" />
-<link rel="Chapter" title="6 Requirements for XSPF players" href="#rfc.section.6" />
-<link rel="Chapter" title="7 Usecases for playlists" href="#rfc.section.7" />
-<link rel="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"></span></b></td>
-</tr>
-<tr>
-<td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2">TOC</b></a></td>
-</tr>
-</table>
-<table summary="header information" width="66%" border="0" cellpadding="1" cellspacing="1">
-<tr>
-<td class="header">Playlist Ad-Hoc Group</td>
-<td class="header">L. Gonze</td>
-</tr>
-<tr>
-<td class="header"></td>
-<td class="header">M. Friedrich</td>
-</tr>
-<tr>
-<td class="header"></td>
-<td class="header">R. Kaye</td>
-</tr>
-<tr>
-<td class="header"></td>
-<td class="header">D. Brown</td>
-</tr>
-<tr>
-<td class="header"></td>
-<td class="header">January 2005</td>
-</tr>
-</table>
-<p class="title">XSPF Version 1<br />
-<span class="filename">XML Shareable Playlist Format ("spiff")</span></p>
-<h1>Abstract</h1>
-<p>We describe an XML playlist format which is open, moderately simple, and carefully engineered.</p>
-<hr class="noprint" />
-<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;">
-<tr>
-<td style="background-color: #000000; text-align: center; vertical-align: middle; height: 2.5em;"><b><span class="RFC"></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" 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.10.1 <a href="#rfc.section.4.1.1.2.10.1">elements</a></b><br />
-<b>4.1.1.2.10.1.1 <a href="#rfc.section.4.1.1.2.10.1.1">link</a></b><br />
-<b>4.1.1.2.10.1.2 <a href="#rfc.section.4.1.1.2.10.1.2">identifier</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>§ <a href="#rfc.references">References</a></b><br />
-<b>§ <a href="#rfc.authors">Author's Addresses</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" 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 digital music 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 digital music 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 a typical music player — it describes layouts in time, while XSPF describes concepts common among music 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 a 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" id="rfc.figure.u.1"></a></div>
-<p>A very simple document looks like this:</p>
-<pre>
-<?xml version="1.0" encoding="UTF-8"?>
+ body
+ {
+ direction: ltr;
+ background-color: white;
+ color: #000000;
+ font-family: Helvetica, sans-serif;
+ font-size:0.9em;
+ }
+ a, abbr
+ {
+ text-decoration: none;
+ }
+ a:hover, a:active
+ {
+ text-decoration: underline;
+ }
+ h1
+ {
+ color: #333333;
+ line-height: 1.2em;
+ page-break-after: avoid;
+ }
+ h2
+ {
+ color: #000000;
+ page-break-after: avoid;
+ }
+ h3
+ {
+ color: #000000;
+ page-break-after: avoid;
+ }
+ p
+ {
+ margin-left: 2em;
+ margin-right: 2em;
+ }
+ .bold { font-weight: bold; }
+ pre
+ {
+ padding: 1em;
+ background-color: #FFFFE0;
+ color: black;
+ }
+ .topnowrap
+ {
+ margin: 0;
+ vertical-align: top;
+ white-space: nowrap;
+ }
+ .theader
+ {
+ width: 80%; border: 0; padding: 0.05em; margin: 0.1em
+ }
+ .header
+ {
+ float: left;
+ width: 40%;
+ color: #ffffff;
+ background-color: #666666;
+ vertical-align: top;
+ padding: 1px;
+ margin: 1px;
+ }
+ .link2
+ {
+ color: #ffffff;
+ font-weight: bold;
+ text-decoration: none;
+ font-size: 70%;
+ }
+ .toc
+ {
+ margin-left: auto;
+ margin-right: 0;
+ float: right;
+ width: 2.5em;
+ background-color: #990000;
+ color: white;
+ text-align: center;
+ vertical-align: middle;
+ height: 1.4em;
+ }
+ .title
+ {
+ clear: both;
+ color: #990000;
+ font-size: 150%;
+ line-height: 1.1em;
+ font-weight: bold;
+ text-align: right;
+ padding-right: 2em;
+ }
+ .filename
+ {
+ color: #333333;
+ font-weight: bold;
+ font-size: 80%;
+ line-height: 1.2em;
+ text-align: right;
+ }
+ @media print {
+ .toc {display:none;}
+ .noprint {display:none;}
+ }
+ ]]></style>
+ <link rel="Contents" href="#rfc.toc"/>
+ <link rel="Author" href="#rfc.authors"/>
+ <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="schema.DC" href="http://purl.org/dc/elements/1.1/"/>
+ <meta name="DC.Creator" content="Lucas Gonze, Matthias Friedrich, Robert Kaye"/>
+ </head>
+ <body>
+ <div class="toc">
+ <a href="#rfc.toc"><span class="link2">TOC</span></a>
+ </div>
+ <div class="theader">
+ <div class="header">Playlist Ad-Hoc Group</div>
+ <div class="header">L. Gonze</div>
+ </div>
+ <div class="theader">
+ <div class="header"> </div>
+ <div class="header">M. Friedrich</div>
+ </div>
+ <div class="theader">
+ <div class="header"> </div>
+ <div class="header">R. Kaye</div>
+ </div>
+ <div class="theader">
+ <div class="header"> </div>
+ <div class="header">January 2004-November 2006</div>
+ </div>
+ <div class="title"><abbr title="XML Shareable Playlist Format">XSPF</abbr> Version 1<br/>
+ <span class="filename">XML Shareable Playlist Format ("spiff")</span></div>
+ <div><h1>Abstract</h1>
+ <p>We describe an <abbr title="Extensible Markup Language">XML</abbr> playlist format which is open, moderately simple, and carefully engineered.</p></div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.toc">Table of Contents</a></h1>
+ <p><span class="bold">1 <a href="#rfc.section.1">Introduction</a></span><br/>
+ <span class="bold">1.1 <a href="#rfc.section.1.1">Example</a></span><br/>
+ <span class="bold">2 <a href="#rfc.section.2">Administration</a></span><br/>
+ <span class="bold">2.1 <a href="#rfc.section.2.1">History</a></span><br/>
+ <span class="bold">2.2 <a href="#rfc.section.2.2">Acknowledgements</a></span><br/>
+ <span class="bold">2.3 <a href="#rfc.section.2.3">terminology</a></span><br/>
+ <span class="bold">2.3.1 <a href="#rfc.section.2.3.1">URI, URLs and URNs</a></span><br/>
+ <span class="bold">2.3.2 <a href="#rfc.section.2.3.2">Requirements notation</a></span><br/>
+ <span class="bold">3 <a href="#rfc.section.3">Abstractions</a></span><br/>
+ <span class="bold">3.1 <a href="#rfc.section.3.1">Defining playlists</a></span><br/>
+ <span class="bold">3.2 <a href="#rfc.section.3.2">What a playlist is not</a></span><br/>
+ <span class="bold">3.3 <a href="#rfc.section.3.3">Shareability</a></span><br/>
+ <span class="bold">3.4 <a href="#rfc.section.3.4">Content resolver</a></span><br/>
+ <span class="bold">3.5 <a href="#rfc.section.3.5">Fuzzy names</a></span><br/>
+ <span class="bold">4 <a href="#rfc.section.4">Element definitions</a></span><br/>
+ <span class="bold">4.1 <a href="#rfc.section.4.1">elements</a></span><br/>
+ <span class="bold">4.1.1 <a href="#rfc.section.4.1.1">playlist</a></span><br/>
+ <span class="bold">4.1.1.1 <a href="#rfc.section.4.1.1.1">attributes</a></span><br/>
+ <span class="bold">4.1.1.1.1 <a href="#rfc.section.4.1.1.1.1">xmlns</a></span><br/>
+ <span class="bold">4.1.1.1.2 <a href="#rfc.section.4.1.1.1.2">version</a></span><br/>
+ <span class="bold">4.1.1.2 <a href="#rfc.section.4.1.1.2">elements</a></span><br/>
+ <span class="bold">4.1.1.2.1 <a href="#rfc.section.4.1.1.2.1">title</a></span><br/>
+ <span class="bold">4.1.1.2.2 <a href="#rfc.section.4.1.1.2.2">creator</a></span><br/>
+ <span class="bold">4.1.1.2.3 <a href="#rfc.section.4.1.1.2.3">annotation</a></span><br/>
+ <span class="bold">4.1.1.2.4 <a href="#rfc.section.4.1.1.2.4">info</a></span><br/>
+ <span class="bold">4.1.1.2.5 <a href="#rfc.section.4.1.1.2.5">location</a></span><br/>
+ <span class="bold">4.1.1.2.6 <a href="#rfc.section.4.1.1.2.6">identifier</a></span><br/>
+ <span class="bold">4.1.1.2.7 <a href="#rfc.section.4.1.1.2.7">image</a></span><br/>
+ <span class="bold">4.1.1.2.8 <a href="#rfc.section.4.1.1.2.8">date</a></span><br/>
+ <span class="bold">4.1.1.2.9 <a href="#rfc.section.4.1.1.2.9">license</a></span><br/>
+ <span class="bold">4.1.1.2.10 <a href="#rfc.section.4.1.1.2.10">attribution</a></span><br/>
+ <span class="bold">4.1.1.2.11 <a href="#rfc.section.4.1.1.2.11">link</a></span><br/>
+ <span class="bold">4.1.1.2.11.1 <a href="#rfc.section.4.1.1.2.11.1">attributes</a></span><br/>
+ <span class="bold">4.1.1.2.11.1.1 <a href="#rfc.section.4.1.1.2.11.1.1">rel</a></span><br/>
+ <span class="bold">4.1.1.2.11.2 <a href="#rfc.section.4.1.1.2.11.2">content</a></span><br/>
+ <span class="bold">4.1.1.2.12 <a href="#rfc.section.4.1.1.2.12">meta</a></span><br/>
+ <span class="bold">4.1.1.2.12.1 <a href="#rfc.section.4.1.1.2.12.1">attributes</a></span><br/>
+ <span class="bold">4.1.1.2.12.1.1 <a href="#rfc.section.4.1.1.2.12.1.1">rel</a></span><br/>
+ <span class="bold">4.1.1.2.12.2 <a href="#rfc.section.4.1.1.2.12.2">content</a></span><br/>
+ <span class="bold">4.1.1.2.13 <a href="#rfc.section.4.1.1.2.13">extension</a></span><br/>
+ <span class="bold">4.1.1.2.13.1 <a href="#rfc.section.4.1.1.2.13.1">attributes</a></span><br/>
+ <span class="bold">4.1.1.2.13.1.1 <a href="#rfc.section.4.1.1.2.13.1.1">application</a></span><br/>
+ <span class="bold">4.1.1.2.13.2 <a href="#rfc.section.4.1.1.2.13.2">content</a></span><br/>
+ <span class="bold">4.1.1.2.14 <a href="#rfc.section.4.1.1.2.14">trackList</a></span><br/>
+ <span class="bold">4.1.1.2.14.1 <a href="#rfc.section.4.1.1.2.14.1">elements</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1 <a href="#rfc.section.4.1.1.2.14.1.1">track</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1 <a href="#rfc.section.4.1.1.2.14.1.1.1">elements</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.1 <a href="#rfc.section.4.1.1.2.14.1.1.1.1">location</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.2 <a href="#rfc.section.4.1.1.2.14.1.1.1.2">identifier</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.3 <a href="#rfc.section.4.1.1.2.14.1.1.1.3">title</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.4 <a href="#rfc.section.4.1.1.2.14.1.1.1.4">creator</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.5 <a href="#rfc.section.4.1.1.2.14.1.1.1.5">annotation</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.6 <a href="#rfc.section.4.1.1.2.14.1.1.1.6">info</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.7 <a href="#rfc.section.4.1.1.2.14.1.1.1.7">image</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.8 <a href="#rfc.section.4.1.1.2.14.1.1.1.8">album</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.9 <a href="#rfc.section.4.1.1.2.14.1.1.1.9">trackNum</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.10 <a href="#rfc.section.4.1.1.2.14.1.1.1.10">duration</a></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.11 <a href="#rfc.section.4.1.1.2.14.1.1.1.11">link</a></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.12 <a href="#rfc.section.4.1.1.2.14.1.1.1.12">meta</a></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">4.1.1.2.14.1.1.1.13 <a href="#rfc.section.4.1.1.2.14.1.1.1.13">extension</a></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">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></span><br/>
+ <span class="bold">5 <a href="#rfc.section.5">Requirements for XSPF generators</a></span><br/>
+ <span class="bold">6 <a href="#rfc.section.6">Requirements for XSPF players</a></span><br/>
+ <span class="bold">6.1 <a href="#rfc.section.6.1">Graceful failure</a></span><br/>
+ <span class="bold">6.2 <a href="#rfc.section.6.2">Relative paths</a></span><br/>
+ <span class="bold">6.3 <a href="#rfc.section.6.3">Extension URIs</a></span><br/>
+ <span class="bold">§ <a href="#rfc.references">References</a></span><br/>
+ <span class="bold">§ <a href="#rfc.authors">Author's Addresses</a></span><br/>
+ <span class="bold">§ <a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></span><br/></p>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.1">1</a> Introduction</h1>
+ <div style="margin-left: 8px;">
+ <div><a 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 (<abbr title="HyperText Markup Language">HTML</abbr>), weblogs (<abbr title="Really Simple Syndication">RSS</abbr>/Atom), and web graphs (<abbr title="Resource Description Framework">RDF</abbr>/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 id="rfc.section.1.p.2"></a></div>
+ <p>It is also evident that existing playlist formats fall short. <abbr title="Advanced Stream Redirector">ASX</abbr> (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. <abbr title="MPEG Version 3.0 URL">M3U</abbr>, RAM, and M4U are flat files; QuickTime is binary; Pls is in the Windows .ini format; Gnomoradio RDF is RDF, not XML. <abbr title="Synchronized Multimedia Integration Language">SMIL</abbr> addresses a much larger problem space than the average digital music 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 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 digital music 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 a typical music player — it describes layouts in time, while XSPF describes concepts common among music 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 a player that the text is a comment and say nothing about formatting.</p>
+ <h2><a id="rfc.section.1.1">1.1</a> Example</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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:///music/song_1.ogg</location></track>
+ <track><location>file:///music/song_2.flac</location></track>
+ <track><location>file:///music/song_3.mp3</location></track>
+ </trackList>
+</playlist></pre>
+ <div><a 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>file:///music/song_1.ogg</location></track>
- <track><location>file:///music/song_2.flac</location></track>
- <track><location>file:///music/song_3.mp3</location></track>
- </trackList>
-</playlist>
-
-</pre>
-<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/">
+ <track><location>http://example.net/song_1.ogg</location></track>
+ <track><location>http://example.net/song_2.flac</location></track>
+ <track><location>http://example.com/song_3.mp3</location></track>
+ </trackList>
+ </playlist></pre></div>
+ </div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.2">2</a> Administration</h1>
+ <div style="margin-left: 8px;">
+ <h2><a id="rfc.section.2.1">2.1</a> History</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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. Between August and November of 2006 we did a final round of improvements to the drafting, limiting changes to those which did not require any implementation to be modified. </p>
+ <div><a id="rfc.section.2.1.p.2"></a></div>
+ <p>This document describes version 1, which is frozen and code-ready.</p>
+ <div><a 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 id="rfc.section.2.2">2.2</a> Acknowledgements</h2>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.2.2.p.1"></a></div>
+ <p>Our project was started by Ian C. Rogers and Robert Kaye. The contributions of Dan Brickley, Kevin Marks and Dave Brown strongly influenced aspects of the design. We are grateful for comments and feedback from Ryan Shaw, Alf Eaton, Steve Gedikian, Russell Garrett, and Ben Tesch. We would like to acknowledge our debt to Sebastian Pipping and Ivo Emanuel Gonçalves, without whom the 2006 revisions would not have been possible. Special thanks to the developers Tomas Franzén (who participated in our work from the very beginning), Jim Garrison, Brander Lien, and Fabricio Zuardi, and to everyone who contributed their time and skill on the mailing list and wiki. We would especially like to thank our hosts at the Metabrainz Foundation and the Xiph.org Foundation for their generosity.</p>
+ </div>
+ <h2><a id="rfc.section.2.3">2.3</a> terminology</h2>
+ <div style="margin-left: 8px;">
+ <h3><a id="rfc.section.2.3.1">2.3.1</a> <abbr title="Uniform Resource Identifier">URI</abbr>, <abbr title="Uniform Resource Locator">URL</abbr>s and <abbr title="Uniform Resource Name">URN</abbr>s</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.2.3.1.p.1"></a></div>
+ <p>We use the term <cite>URI</cite> in this document regardless of whether a given URI specifies the location of a resource (a URL) or its name (a URN) independent of location.</p>
+ <div><a 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 id="rfc.section.2.3.2">2.3.2</a> Requirements notation</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 are to be interpreted as
+ described in <a href="#RFC2119" title="Key words for use in
+ RFCs to Indicate Requirement Levels">[RFC2119]</a>.</p>
+ </div>
+ </div>
+ </div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.3">3</a> Abstractions</h1>
+ <div style="margin-left: 8px;">
+ <h2><a id="rfc.section.3.1">3.1</a> Defining playlists</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 id="rfc.section.3.2">3.2</a> What a playlist is not</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 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 id="rfc.section.3.3">3.3</a> Shareability</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 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 URI 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 id="rfc.section.3.4">3.4</a> Content resolver</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 software music players on the PC have some sort of cache for file information. This cache stores a list, or catalog, of available files and metadata from ID3 tags and other sources. XSPF is not a catalog format. XSPF exists only to say which songs to play. Almost everything in XSPF is for the purpose of answering the question <em>which resource</em>, rather than the question <em>what is this resource</em>.</p>
+ <div><a 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 URIs. A content resolver would be smart enough to keep your playlists from breaking when you move your media from /oggs to /music/ogg. It would be able to figure out that a playlist entry by the artist "Hank Williams" with the title "Your Cheating Heart" could be satisfied by the file /vorbis/hankwilliams/yourcheatingheart.ogg. It might even know how to query the iTunes music store or another online provider to locate and download a missing song.</p>
+ <div><a 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 id="rfc.section.3.5">3.5</a> Fuzzy names</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 URIs, filesystem paths and secure hashes, but also for query-based identifiers — free text fields like artist and work title and numeric fields for song length, all of which together should be enough for a good content resolver to turn into files.</p>
+ </div>
+ </div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.4">4</a> Element definitions</h1>
+ <div style="margin-left: 8px;">
+ <h2><a id="rfc.section.4.1">4.1</a> elements</h2>
+ <div style="margin-left: 8px;">
+ <h3><a id="rfc.section.4.1.1">4.1.1</a> playlist</h3>
+ <div style="margin-left: 8px;">
+ <h3><a id="rfc.section.4.1.1.1">4.1.1.1</a> attributes</h3>
+ <div style="margin-left: 8px;">
+ <h3><a id="rfc.section.4.1.1.1.1">4.1.1.1.1</a> xmlns</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.1.1.p.1"></a></div>
+ <p>http://xspf.org/ns/0/</p>
+ </div>
+ <h3><a id="rfc.section.4.1.1.1.2">4.1.1.1.2</a> version</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.1.2.p.1"></a></div>
+ <p>1</p>
+ </div>
+ <div><a 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 id="rfc.section.4.1.1.2">4.1.1.2</a> elements</h3>
+ <div style="margin-left: 8px;">
+ <h3><a id="rfc.section.4.1.1.2.1">4.1.1.2.1</a> title</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 id="rfc.section.4.1.1.2.2">4.1.1.2.2</a> creator</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 id="rfc.section.4.1.1.2.3">4.1.1.2.3</a> annotation</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 id="rfc.section.4.1.1.2.4">4.1.1.2.4</a> info</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.4.p.1"></a></div>
+ <p>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.</p>
+ </div>
+ <h3><a id="rfc.section.4.1.1.2.5">4.1.1.2.5</a> location</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.5.p.1"></a></div>
+ <p>Source URI for this playlist. xspf:playlist elements MAY contain exactly one.</p>
+ </div>
+ <h3><a id="rfc.section.4.1.1.2.6">4.1.1.2.6</a> identifier</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 URI. xspf:playlist elements MAY contain exactly one.</p>
+ </div>
+ <h3><a id="rfc.section.4.1.1.2.7">4.1.1.2.7</a> image</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.7.p.1"></a></div>
+ <p>URI 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 id="rfc.section.4.1.1.2.8">4.1.1.2.8</a> date</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 id="rfc.section.4.1.1.2.8.p.3"></a></div>
+ <p>In the absence of a timezone, the element MAY be assumed to use Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time").</p>
+ <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 id="rfc.section.4.1.1.2.9">4.1.1.2.9</a> license</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.9.p.1"></a></div>
+ <p>URI 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 id="rfc.section.4.1.1.2.10">4.1.1.2.10</a> attribution</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 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 id="rfc.section.4.1.1.2.11">4.1.1.2.11</a> link</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.11.p.1"></a></div>
+ <p>The link element allows XSPF to be extended without the use of XML namespaces. xspf:playlist elements MAY contain zero or more link elements.</p>
+ <div><a 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 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 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 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 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 id="rfc.section.4.1.1.2.11.2.p.1"></a></div>
+ <p>URI of a resource.</p>
+ </div>
+ </div>
+ <h3><a id="rfc.section.4.1.1.2.12">4.1.1.2.12</a> meta</h3>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.4.1.1.2.12.p.1"></a></div>
+ <p>The meta element allows metadata fields to be added to XSPF. xspf:playlist elements MAY contain zero or more meta elements.</p>
+ <div><a id="rfc.figure.u.6"></a></div>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <h3><a 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 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 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 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 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 id="rfc.section.4.1.1.2.13">4.1.1.2.13</a> extension</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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. 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 id="rfc.figure.u.7"></a></div>
+ <pre><playlist version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
+ <extension application="http://example.com">
+ <cl:clip start="25000" end="34500"/>
+ </extension>
+ <trackList />
+</playlist></pre>
+ <h3><a 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 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 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 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 id="rfc.section.4.1.1.2.13.2.p.1"></a></div>
+ <p>nested XML.</p>
+ </div>
+ </div>
+ <h3><a id="rfc.section.4.1.1.2.14">4.1.1.2.14</a> trackList</h3>
+ <div style="margin-left: 8px;">
+ <div><a 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 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 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 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 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 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 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 id="rfc.section.4.1.1.2.14.1.1.1.1.p.1"></a></div>
+ <p>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.</p>
+ </div>
+ <h3><a 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 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. MUST be a legal URI. xspf:track elements MAY contain zero or more identifier elements.</p>
+ <p>For example, the URI <a href="http://musicbrainz.org/track/7e1d6f5f-0ac3-4889-8b57-506a67b459fc.html">http://musicbrainz.org/track/7e1d6f5f-0ac3-4889-8b57-506a67b459fc.html</a> is an identifier for a specific song, but dereferencing that identifier will not yield a copy of the song.</p>
+ </div>
+ <h3><a 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 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 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 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 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 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 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 id="rfc.section.4.1.1.2.14.1.1.1.6.p.1"></a></div>
+ <p>URI of a place where this resource can be bought or more info can be found. xspf:track elements MAY contain exactly one.</p>
+ </div>
+ <h3><a 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 id="rfc.section.4.1.1.2.14.1.1.1.7.p.1"></a></div>
+ <p>URI of an image to display for the duration of the track. xspf:track elements MAY contain exactly one.</p>
+ </div>
+ <h3><a 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 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 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 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 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 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 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 id="rfc.section.4.1.1.2.14.1.1.1.11.p.1"></a></div>
+ <p>The link element allows XSPF to be extended without the use of XML namespaces. xspf:track elements MAY contain zero or more link elements.</p>
+ <div><a 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 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 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 id="rfc.section.4.1.1.2.14.1.1.1.11.1.1.p.1"></a></div>
+ <p>URI of a resource type.</p>
+ </div>
+ </div>
+ <h3><a 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 id="rfc.section.4.1.1.2.14.1.1.1.11.2.p.1"></a></div>
+ <p>URI of a resource.</p>
+ </div>
+ </div>
+ <h3><a 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 id="rfc.section.4.1.1.2.14.1.1.1.12.p.1"></a></div>
+ <p>The meta element allows metadata fields to be added to xspf:track elements. xspf:track elements MAY contain zero or more meta elements.</p>
+ <div><a id="rfc.figure.u.9"></a></div>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <h3><a 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 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 id="rfc.section.4.1.1.2.14.1.1.1.12.1.1.p.1"></a></div>
+ <p>URI of a resource defining the metadata.</p>
+ </div>
+ </div>
+ <h3><a 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 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:track elements MAY contain exactly one.</p>
+ </div>
+ </div>
+ <h3><a 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 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. The purpose is to allow nested XML, which the meta and link elements do not. xspf:track elements MAY contain zero or more extension elements.</p>
+ <div><a id="rfc.figure.u.10"></a></div>
+ <pre><playlist version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
<trackList>
- <track><location>http://example.net/song_1.ogg</location></track>
- <track><location>http://example.net/song_2.flac</location></track>
- <track><location>http://example.com/song_3.mp3</location></track>
+ <track>
+ <extension application="http://example.com">
+ <cl:clip start="25000" end="34500"/>
+ </extension>
+ </track>
</trackList>
-</playlist>
-
-</pre></div>
-</div>
-<hr class="noprint" />
-<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;">
-<tr>
-<td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2">TOC</b></a></td>
-</tr>
-</table>
-<h1><a name="rfc.section.2" id="rfc.section.2">2</a> Administration</h1>
-<div style="margin-left: 8px;">
-<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" 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. Between August and September of 2006 we did a final round of improvements to the drafting, limiting changes to those which did not require any implementation to be modified. </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 frozen and code-ready. </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" id="rfc.section.2.2">2.2</a> Acknowledgements</h2>
-<div style="margin-left: 8px;">
-<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. We would like to acknowledge the debt we owe to Sebastian Pipping and Ivo Emanuel Gonçalves, whose contributions to the final revision of the version 1 specification were instrumental. 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" id="rfc.section.2.3">2.3</a> terminology</h2>
-<div style="margin-left: 8px;">
-<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" id="rfc.section.2.3.1.p.1"></a></div>
-<p>We use the term <cite>URI</cite> in this document regardless of whether a given URI specifies the location of a resource (a URL) or its name (a URN) independent of location.
-<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" 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" 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" id="rfc.section.3">3</a> Abstractions</h1>
-<div style="margin-left: 8px;">
-<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" 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" 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" 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" id="rfc.section.3.3">3.3</a> Shareability</h2>
-<div style="margin-left: 8px;">
-<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 URI 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" 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" 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 software music players on the PC have some sort of cache for file information. This cache stores a list, or catalog, of available files and metadata from ID3 tags and other sources. XSPF is not a catalog format. XSPF exists only to say which songs to play. Almost everything in XSPF is for the purpose of answering the question <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 URIs. A content resolver would be smart enough to keep your playlists from breaking when you move your media from /oggs to /music/ogg. It would be able to figure out that a playlist entry by the artist "Hank Williams" with the title "Your Cheating Heart" could be satisfied by the file /vorbis/hankwilliams/yourcheatingheart.ogg. It might even know how to query the iTunes music store or another online provider to locate and download a missing song.</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" 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" 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 URIs, filesystem paths and secure hashes, but also for query-based identifiers — free text fields like artist and work title and numeric fields for song length, all of which together should be enough for a good content resolver to turn into files.</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" id="rfc.section.4">4</a> Element definitions</h1>
-<div style="margin-left: 8px;">
-<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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" 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" id="rfc.section.4.1.1.2.4.p.1"></a></div>
-<p>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.</p>
-</div>
-<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" id="rfc.section.4.1.1.2.5.p.1"></a></div>
-<p>Source URI for this playlist. xspf:playlist elements MAY contain exactly one.</p>
-</div>
-<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" 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 URI. xspf:playlist elements MAY contain exactly one.</p>
-</div>
-<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" id="rfc.section.4.1.1.2.7.p.1"></a></div>
-<p>URI 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" 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" 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" id="rfc.section.4.1.1.2.8.p.3"></a></div>
-<p>In the absence of a timezone, the element MAY be assumed to use Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time").</p>
-<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" 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" id="rfc.section.4.1.1.2.9.p.1"></a></div>
-<p>URI 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" 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" 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" 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" 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" 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" 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" 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" 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" id="rfc.section.4.1.1.2.11.2.p.1"></a></div>
-<p>URI of a resource.</p>
-</div>
-</div>
-<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" 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" 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" 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" 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" 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" 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" 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" 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 version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
- <extension application="http://example.com">
- <cl:clip start="25000" end="34500"/>
- </extension>
- <trackList />
-</playlist>
-
-</pre>
-<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" 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" 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" 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" 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" 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" 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" 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" 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" 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" id="rfc.section.4.1.1.2.14.1.1.1.1.p.1"></a></div>
-<p>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.</p>
-</div>
-<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" 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. MUST be a legal URI. xspf:track elements MAY contain zero or more identifier elements.</p>
-<p>For example, the URI <a href="http://musicbrainz.org/track/7e1d6f5f-0ac3-4889-8b57-506a67b459fc.html">http://musicbrainz.org/track/7e1d6f5f-0ac3-4889-8b57-506a67b459fc.html</a> is an identifier for a specific song, but dereferencing that identifier will not yield a copy of the song.</p>
-</div>
-<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" 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" 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" 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" 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" 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" 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" id="rfc.section.4.1.1.2.14.1.1.1.6.p.1"></a></div>
-<p>URI of a place where this resource can be bought or more info can be found. xspf:track elements MAY contain exactly one.</p>
-</div>
-<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" id="rfc.section.4.1.1.2.14.1.1.1.7.p.1"></a></div>
-<p>URI 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" 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" 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" 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" 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" 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" 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" 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" 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. xspf:track elements MAY contain zero or more link elements.</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" 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" 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" id="rfc.section.4.1.1.2.14.1.1.1.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.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" id="rfc.section.4.1.1.2.14.1.1.1.11.2.p.1"></a></div>
-<p>URI of a resource.</p>
-</div>
-</div>
-<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" 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. xspf:track elements MAY contain zero or more meta elements.
-</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" 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" 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" id="rfc.section.4.1.1.2.14.1.1.1.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.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" 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:track elements MAY contain exactly one.</p>
-</div>
-</div>
-<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" 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:track 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 version="1" xmlns="http://xspf.org/ns/0/" xmlns:cl="http://example.com">
- <trackList>
- <track>
- <extension application="http://example.com">
- <cl:clip start="25000" end="34500"/>
- </extension>
- </track>
- </trackList>
-</playlist>
-
-</pre>
-<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" 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" 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" 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" id="rfc.section.4.1.1.2.14.1.1.1.13.2.p.1"></a></div>
-<p>nested XML.</p>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-</div>
-<hr class="noprint" />
-<table summary="link to TOC" class="noprint" style="margin-left: auto; margin-right: 0; float: right; width: 2.5em;">
-<tr>
-<td style="background-color: #990000; text-align: center; height: 1.5em;"><a href="#rfc.toc"><b class="link2">TOC</b></a></td>
-</tr>
-</table>
-<h1><a name="rfc.section.5" id="rfc.section.5">5</a> Requirements for XSPF generators</h1>
-<div style="margin-left: 8px;">
-<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).</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" id="rfc.section.6">6</a> Requirements for XSPF players</h1>
-<div style="margin-left: 8px;">
-<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" 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" 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" 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):
+</playlist></pre>
+ <h3><a 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 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 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 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 id="rfc.section.4.1.1.2.14.1.1.1.13.2.p.1"></a></div>
+ <p>nested XML.</p>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ </div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.5">5</a> Requirements for XSPF generators</h1>
+ <div style="margin-left: 8px;">
+ <div><a 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).</p>
+ </div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.section.6">6</a> Requirements for XSPF players</h1>
+ <div style="margin-left: 8px;">
+ <h2><a id="rfc.section.6.1">6.1</a> Graceful failure</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 id="rfc.section.6.2">6.2</a> Relative paths</h2>
+ <div style="margin-left: 8px;">
+ <div><a 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 <abbr title="Request for Comments">RFC</abbr> 2396</a>:</p>
+ <pre>The rules for determining the base URI can be be summarized as follows (highest priority to lowest):
The base URI is embedded in the document's content.
- The base URI is that of the encapsulating entity (message,
- document, or none).
+ The base URI is that of the encapsulating entity (message, document, or none).
The base URI is the URI used to retrieve the entity.
- The base URI is defined by the context of the application.
-
-</pre></div>
-<h2><a name="rfc.section.6.3" 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" id="rfc.section.6.3.p.1"></a></div>
-<p>Applications MUST assign unique URIs from their own namespace for each link, meta and extension element. New URIs SHOULD be assigned if syntax and/or semantics of a link, meta or extension element changes.</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" id="rfc.section.7">7</a> Usecases for playlists</h1>
-<div style="margin-left: 8px;">
-<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" 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 a music 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" 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" 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 URI of an audio or video document. Playlists used for this purpose often contain only a single URI. The Pls format, which is used for MP3-based webcasting, and which contains a single URI 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" 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" 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" 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" 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 URIs 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 URIs 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>
-<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" 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" id="rfc.section.7.5.p.1"></a></div>
-<p>Scenario: a digital music player needs to access information about media objects which is too expensive to compute in real time. For a large number of files 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: a digital music 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" 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" 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 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" 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" 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 URIs, 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.references" id="rfc.references">References</a></h1>
-<table summary="References" border="0">
-<tr>
-<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" id="rfc.authors"></a>Author's Addresses</h1>
-<table summary="Authors" width="99%" border="0" cellpadding="0" cellspacing="0">
-<tr>
-<td></td>
-<td>Lucas Gonze</td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td class="right"><b>EMail:</b></td>
-<td><a href="mailto:lucas@gonze.com">lucas@gonze.com</a></td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td></td>
-<td>Matthias Friedrich</td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td class="right"><b>EMail:</b></td>
-<td><a href="mailto:matt@mafr.de">matt@mafr.de</a></td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td></td>
-<td>Robert Kaye</td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td class="right"><b>EMail:</b></td>
-<td><a href="mailto:rob@eorbit.net">rob@eorbit.net</a></td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td></td>
-<td>Dave Brown</td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-<tr>
-<td class="right"><b>EMail:</b></td>
-<td><a href="mailto:dabrown@yahoo-inc.com">dabrown@yahoo-inc.com</a></td>
-</tr>
-<tr>
-<td></td>
-<td></td>
-</tr>
-</table>
-</body>
+ The base URI is defined by the context of the application.</pre></div>
+ <h2><a id="rfc.section.6.3">6.3</a> Extension URIs</h2>
+ <div style="margin-left: 8px;">
+ <div><a id="rfc.section.6.3.p.1"></a></div>
+ <p>Applications MUST assign unique URIs from their own namespace for each link, meta and extension element. New URIs SHOULD be assigned if syntax and/or semantics of a link, meta or extension element changes.</p>
+ </div>
+ </div>
+
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.references">References</a></h1>
+ <div class="topnowrap"><span class="bold"><a id="RFC2119">[RFC2119]</a></span> <a href="mailto:sob@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.</div>
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.authors"></a>Author's Addresses</h1>
+ <div class="topnowrap">
+ <div style="text-align:center;">Lucas Gonze<br/>
+ <span class="bold">E-mail:</span> <a href="mailto:lucas@gonze.com">lucas@gonze.com</a><br/>
+ Matthias Friedrich<br/>
+ <span class="bold">E-mail:</span> <a href="mailto:matt@mafr.de">matt@mafr.de</a><br/>
+ Robert Kaye<br/>
+ <span class="bold">E-mail:</span> <a href="mailto:rob at eorbit.net">rob at eorbit.net</a><br/> </div>
+ </div>
+
+ <hr class="noprint"/>
+ <div class="toc"><a href="#rfc.toc"><span class="link2">TOC</span></a></div>
+ <h1><a id="rfc.ipr">Intellectual Property and Copyright Statements</a></h1>
+ <div style="text-align:center">
+ <p>Copyright © Xiph.org Foundation 2005.</p>
+ <p>The primary author of this work is <a href="http://gonze.com/about">Lucas Gonze</a>. He knows of no patent claims which would restrict usage, and disclaims any such patent claims with regard to his own contributions.</p>
+ <p><!--Creative Commons License--><a rel="license" href="http://creativecommons.org/licenses/by-nd/2.5/"><img alt="Creative Commons License" style="border-width: 0" src="http://creativecommons.org/images/public/somerights20.png"/></a><br/>This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nd/2.5/">Creative Commons Attribution-NoDerivs 2.5 License</a>.<!--/Creative Commons License--><!-- <rdf:RDF xmlns="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
+ <Work rdf:about="">
+ <license rdf:resource="http://creativecommons.org/licenses/by-nd/2.5/" />
+ </Work>
+ <License rdf:about="http://creativecommons.org/licenses/by-nd/2.5/"><permits rdf:resource="http://web.resource.org/cc/Reproduction"/><permits rdf:resource="http://web.resource.org/cc/Distribution"/><requires rdf:resource="http://web.resource.org/cc/Notice"/><requires rdf:resource="http://web.resource.org/cc/Attribution"/></License></rdf:RDF> --></p>
+ </div>
+
+
+
+ </body>
</html>
More information about the commits
mailing list