[xiph-commits] r8971 - trunk/xspf/spec/v0
lgonze at motherfish-iii.xiph.org
lgonze at motherfish-iii.xiph.org
Tue Feb 22 17:13:15 PST 2005
Author: lgonze
Date: 2005-02-22 17:13:10 -0800 (Tue, 22 Feb 2005)
New Revision: 8971
Added:
trunk/xspf/spec/v0/DefaultFormatInXmlVersionThree
trunk/xspf/spec/v0/cvt.pl
trunk/xspf/spec/v0/toc.html
trunk/xspf/spec/v0/toc.pl
trunk/xspf/spec/v0/toc2.pl
trunk/xspf/spec/v0/xspf-design-IN.html
trunk/xspf/spec/v0/xspf-design.html
trunk/xspf/spec/v0/xspf-draft-2.html
trunk/xspf/spec/v0/xspf-draft-2.html.1
trunk/xspf/spec/v0/xspf-draft-3.html
trunk/xspf/spec/v0/xspf-draft-4-IN.html
trunk/xspf/spec/v0/xspf-draft-4.html
trunk/xspf/spec/v0/xspf-draft-5-IN.html
trunk/xspf/spec/v0/xspf-draft-5.html
trunk/xspf/spec/v0/xspf-draft-6-IN.html
trunk/xspf/spec/v0/xspf-draft-6.html
trunk/xspf/spec/v0/xspf-draft-7-IN.html
trunk/xspf/spec/v0/xspf-draft-7.html
trunk/xspf/spec/v0/xspf-draft-8-IN.html
trunk/xspf/spec/v0/xspf-draft-8.html
trunk/xspf/spec/v0/xspf-draft-9-IN.html
trunk/xspf/spec/v0/xspf-draft-9.html
Log:
Check in working files for spec version 0. The toc*.pl scripts are used to convert -IN.html files to release versions.
DefaultFormatInXmlVersionThree is the example playlist we used during initial development.
All of this is now obsolete.
draft-9 became version 1.
Added: trunk/xspf/spec/v0/DefaultFormatInXmlVersionThree
===================================================================
--- trunk/xspf/spec/v0/DefaultFormatInXmlVersionThree 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/DefaultFormatInXmlVersionThree 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,252 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+
+
+
+<title>DefaultFormatInXmlVersionThree - Portable Playlist Wiki</title>
+<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="all" href="/wiki/classic/css/common.css">
+<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="screen" href="/wiki/classic/css/screen.css">
+<link rel="stylesheet" type="text/css" charset="iso-8859-1" media="print" href="/wiki/classic/css/print.css">
+
+
+<link rel="Start" href="/playlist/moin.cgi/FrontPage">
+<link rel="Alternate" title="Wiki Markup" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=raw">
+<link rel="Alternate" media="print" title="Print View" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=print">
+<link rel="Search" href="/playlist/moin.cgi/FindPage">
+<link rel="Index" href="/playlist/moin.cgi/TitleIndex">
+<link rel="Glossary" href="/playlist/moin.cgi/WordIndex">
+<link rel="Help" href="/playlist/moin.cgi/HelpOnFormatting">
+</head>
+
+<body lang="en" dir="ltr">
+
+
+<div id="logo"><a href="/playlist/moin.cgi/FrontPage"><img src="/wiki/img/splotch.png" alt="Portable Playlist Wiki"></a></div>
+<div id="username"><a href="/playlist/moin.cgi/UserPreferences">UserPreferences</a></div>
+<div id="title"><h1><a title="Click here to do a full-text search for this title" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=fullsearch&value=DefaultFormatInXmlVersionThree&literal=1&case=1&context=40">DefaultFormatInXmlVersionThree</a></h1></div>
+<ul id="iconbar">
+<li><a title="Edit" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=edit"><img src="/wiki/classic/img/moin-edit.png" alt="Edit" height="12" width="12"></a></li>
+<li><a title="View" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree"><img src="/wiki/classic/img/moin-show.png" alt="View" height="13" width="12"></a></li>
+<li><a title="Diffs" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=diff"><img src="/wiki/classic/img/moin-diff.png" alt="Diffs" height="11" width="15"></a></li>
+<li><a title="Info" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=info"><img src="/wiki/classic/img/moin-info.png" alt="Info" height="11" width="12"></a></li>
+<li><a title="Subscribe" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=subscribe"><img src="/wiki/classic/img/moin-subscribe.png" alt="Subscribe" height="10" width="14"></a></li>
+<li><a title="Raw" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=raw"><img src="/wiki/classic/img/moin-raw.png" alt="Raw" height="13" width="12"></a></li>
+<li><a title="Print" href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=print"><img src="/wiki/classic/img/moin-print.png" alt="Print" height="14" width="16"></a></li>
+</ul>
+
+<ul id="navibar">
+<li><a href="/playlist/moin.cgi/FrontPage">FrontPage</a></li>
+<li><a href="/playlist/moin.cgi/RecentChanges">RecentChanges</a></li>
+<li><a href="/playlist/moin.cgi/FindPage">FindPage</a></li>
+<li><a href="/playlist/moin.cgi/HelpContents">HelpContents</a></li>
+</ul>
+<hr id="pagetrail">
+
+
+
+<div id="content" lang="en" dir="ltr">
+
+<pre><?xml version="1.0" encoding="UTF-8"?>
+
+<!-- Audit trail:
+
+ June 7, 2004: Fix malformed <location></locator> pair.
+
+ May 12, 2004: Added //playlist at version.
+
+ April 28, 2004: Change namespace to http://xspf.org/ns/0/.
+
+ April 23, 2004: Introduced <meta> and re-introduced <identifier> and <location> -Matthias
+
+ April 15, 2004: Remove cc: namespace and replace with "link
+ rel=license" syntax. Note that the license I selected is
+ http://creativecommons.org/licenses/by-sa/1.0/, which is a
+ decision that members of the playlist WG may want to read and
+ vet. Change Track to track and Playlist to playlist.
+
+ April 4, 2004: Forked this from DefaultVersionInRdfVersionFour.
+ Add link rel="info|location|identifier|image". -Lucas
+
+ March 30, 2004: Made osp: the default namespace to simplify things even more. Switched to
+ plain XML. -Matthias
+
+ March 29, 2004: Forked this from DefaultFormatInRdfVersionTwoB. Radical simplifications:
+ absorbed dc: and mm: into osp namespace. New osp:annotation and osp:title tags. Many
+ other changes! -Lucas
+
+ March 27, 2004: Added osp:comment on head and tracks. Changed
+ dc:creator to proposed new syntax. Corrected namespace URI for
+ osp namespace so that our predicates are resolvable URLs.
+ Tidied dc:title and dc:description contents. -Lucas
+
+ March 24, 2004: I repaired the licensing section and removed the DTD reference. I heard we
+ want to use XML Schema anyway. Now it's OK according to the W3 validator. -Matthias
+
+ March 23, 2004: mayhem removed a stray comma from the namespace decl and added the foaf namespace.
+ Removed double - in comments. Changed a rdf:descriptoin to rdf:description. Mostly parses
+ in the W3 online validator. The CC license stuff has an about it complains about and it
+ doesn't like the DOCTYPE decl
+
+ March 22, 2004: danbri created DefaultFormatInRdfVersionTwoB, fixed dates in audit trail,
+ and changed list syntax from rdf:li/Seq to use Collections. I changed the first
+ osp:attribution block, and also dropped use of dc:source since it didn't parse right even
+ in the original, and isn't clear here what two things the dc:source property would be relating
+ to each other. -danbri
+
+ March 21, 2004: added cc: qualifiers on Agent. Moved attribution
+ dc:source elements into an osp:attribution element. deleted
+ dc:rights. changed dc:creator to contain a foaf:Person. Forked new
+ file DefaultFormatInRdfVersionTwo from DefaultFormatInRdf -LucasGonze
+
+ March 13, 2004: created DefaultFormatInRdf -LucasGonze
+
+ -->
+
+<playlist version="0" xmlns="http://xspf.org/ns/0/">
+
+ <title>A Sample Playlist</title>
+
+ <annotation>An example of the default format playlist expressed in XML.</annotation>
+
+ <!-- element content is name of the author. Text, not HTML. -->
+ <creator>The Portable Playlist Working Group</creator>
+
+ <!-- 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.
+ -->
+ <info>http://playlist.musicbrainz.org/playlist/moin.cgi/FrontPage</info>
+
+ <!-- source URL for this playlist -->
+ <location>http://playlist.musicbrainz.org/playlist/moin.cgi/DefaultFormatInXmlVersionThree</location>
+
+ <!-- canonical ID for this playlist -->
+ <identifier>urn:experimental:foo</identifier>
+
+ <!-- album art to display -->
+ <image>http://example.org/foo.jpg</image>
+
+ <!-- additional link, user defined -->
+ <link rel="http://whatever.org/sponsor">nobody</link>
+
+ <!-- additional metadata, user defined -->
+ <meta property="http://example.org/key">value</meta>
+
+ <!-- Creation date -->
+ <date>2004-03-21</date>
+
+ <!-- If you make a modified copy of a playlist, move its
+ <location> element to the top of this list. -->
+ <attribution>
+ <location>http://playlist.musicbrainz.org/playlist/moin.cgi/DefaultFormatInXmlVersionTwo</location>
+ <location>http://playlist.musicbrainz.org/playlist/moin.cgi/DefaultFormatInRdfVersionFour</location>
+ <location>http://playlist.musicbrainz.org/playlist/moin.cgi/DefaultFormatInRdfVersionTwoB</location>
+ <location>http://playlist.musicbrainz.org/playlist/moin.cgi/DefaultFormatInRdf</location>
+ <location>http://www.stud.uni-karlsruhe.de/~uy7l/playlist/example3.xml</location>
+ </attribution>
+
+ <!-- The URL of a document that describes the license under
+ which this playlist was released. -->
+ <license>http://creativecommons.org/licenses/by-sa/1.0/</license>
+
+ <trackList>
+
+ <track>
+
+ <!-- We have this song on disk -->
+ <location>file:///mp3s/tori/space_dog.mp3</location>
+
+ <!-- An image to display while the song is playing -->
+ <image>http://example.org/bar.mp3</image>
+
+ <!-- any kind of comment on the song. -->
+ <annotation>My mom loves this song. This is weird.</annotation>
+
+ <!-- ALL of this is sloppy. It is here for fuzzy lookups, not to be canonical. -->
+ <creator>Tori Amos</creator>
+ <title>Space Dog</title>
+ <album>Under the Pink</album>
+ <trackNum>11</trackNum>
+ <duration>313</duration> <!-- in seconds -->
+
+ </track>
+
+ <track>
+
+ <!-- We know the MusicBrainz id of this song and we also know where
+ it can be bought. An application (or content resolver) could check
+ the prefixes to see if it supports that kind of identifier. -->
+ <identifier>http://musicbrainz.org/track/28af4859-5f9e-483f-8ff3-3dc1e5a6f19d</identifier>
+
+ <!-- A place where this song can be bought or more info can be found. -->
+ <info>http://some.webshop.invalid/songs?id=xyz</info>
+
+ </track>
+
+ <track>
+
+ <!-- We know where to find this song on the web -->
+ <location>http://www.mafr.de/not_there/find_the_river.mp3</location>
+
+ <!-- A canonical identifier for this song, perhaps it can be
+ used to find a bag of bytes containing the song. -->
+ <identifier>http://musicbrainz.org/track/c6b633b9-5d94-426a-aad1-1b394e2be75</identifier>
+
+ </track>
+
+ <track>
+
+ <!-- We don't have this song on disk (or don't know where it
+ is) and we don't know a URL for it, but we do have a
+ canonical identifier that may help find it. -->
+ <identifier>urn:sha1:01c2f6b84888970732259dad9faa8b42e2e31f6b</identifier>
+
+ </track>
+
+ <!-- The most simple applications could create this kind of
+ entry. When parsing playlists, everything except the
+ file:/// ids can be ignored. That way conversion
+ from/to m3u is simple. -->
+ <track>
+ <location>file:///mp3s/Bob_Dylan/Visions_Of_Johanna.mp3</location>
+ <meta property="http://some.domain.invalid/tempo">slow</meta>
+ </track>
+
+
+ </trackList>
+
+</playlist>
+</pre></div>
+
+
+
+<div id="footer">
+<div id="credits">
+<p>
+ <a href="http://moinmoin.wikiwikiweb.de/">MoinMoin Powered</a><br>
+ <a href="http://www.python.org/">
+ <img src="/wiki/classic/img/PythonPowered.png" width="55" height="22" alt="PythonPowered">
+ </a>
+</p>
+</div>
+
+
+<a href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=refresh&arena=Page.py&key=DefaultFormatInXmlVersionThree.text_html">RefreshCache</a> for this page (cached 2004-06-09 21:37:12)<br>
+<p><a href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=edit">EditText</a> of this page (last edited 2004-06-09 21:37:12 by <span title="65.94.228.143=MTL-HSE-ppp201873.qc.sympatico.ca">MTL-HSE-ppp201873</span>)</p>
+
+<form method="POST" action="/playlist/moin.cgi/DefaultFormatInXmlVersionThree">
+<p>
+<input type="hidden" name="action" value="inlinesearch">
+<input type="hidden" name="context" value="40">
+<a href="/playlist/moin.cgi/FindPage?value=DefaultFormatInXmlVersionThree">FindPage</a> or search titles <input type="text" name="text_title" value="" size="15" maxlength="50"><input type="image" src="/wiki/classic/img/moin-search.png" name="button_title" alt="[?]">, full text <input type="text" name="text_full" value="" size="15" maxlength="50"><input type="image" src="/wiki/classic/img/moin-search.png" name="button_full" alt="[?]"> or <a href="/playlist/moin.cgi/SiteNavigation">SiteNavigation</a>
+</p>
+</form>
+
+<p>Or try one of these actions: <a href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=LikePages">LikePages</a>, <a href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=LocalSiteMap">LocalSiteMap</a>, <a href="/playlist/moin.cgi/DefaultFormatInXmlVersionThree?action=SpellCheck">SpellCheck</a></p>
+
+</div>
+
+</body>
+</html>
+
Added: trunk/xspf/spec/v0/cvt.pl
===================================================================
--- trunk/xspf/spec/v0/cvt.pl 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/cvt.pl 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,13 @@
+#!/usr/bin/perl
+
+my @doc = ();
+my @arr = ();
+while(<STDIN>){
+
+ if( m/<h(.)>([^<]*)<\/h.>/ && $1 ne "1" && $2 ne ""){
+ s/<h(.)>([^<]*)<\/h.>/<\/dd>\n<\/dl>\n<dl>\n<dt class="header$1">$2<\/dt>\n<dd>\n/;
+ }
+
+ print;
+}
+
Added: trunk/xspf/spec/v0/toc.html
===================================================================
--- trunk/xspf/spec/v0/toc.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/toc.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,49 @@
+ <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#Abstract">Abstract</a></li>
+<li><a href="#Publication Status and authorship">Publication Status and authorship</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Element Definitions">Element Definitions</a></li>
+<li><a href="#xml">xml</a></li>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+<li><a href="#playlist">playlist</a></li>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li><a href="#rel">rel</a></li>
+<li><a href="#meta">meta</a></li>
+<li><a href="#rel">rel</a></li>
+<li><a href="#trackList">trackList</a></li>
+<li><a href="#track">track</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li><a href="#rel">rel</a></li>
+<li><a href="#meta">meta</a></li>
+<li><a href="#rel">rel</a></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li><a href="#How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li><a href="#Todo list">Todo list</a></li>
+
+ </ol>
+
Added: trunk/xspf/spec/v0/toc.pl
===================================================================
--- trunk/xspf/spec/v0/toc.pl 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/toc.pl 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,52 @@
+#!/usr/bin/perl
+
+# name all dt elements and compile a table of contents based on them
+
+my @doc = ();
+my @arr = ();
+while(<STDIN>){
+
+ if( m/<dt>([^<]*)<\/dt>/ ){
+ my $esc = $1;
+ my $txt = $1;
+ $esc =~ s/\W//g;
+ push(@arr, "<li><a href=\"\#$esc\">$txt</a></li>");
+ s/<dt>([^<]*)<\/dt>/<dt><a name="$esc"\/>$txt<\/dt>/;
+ } elsif( m/<h(.)>([^<]*)<\/h.>/ && $1 ne "1"){
+ my $degree = $1;
+ my $txt = $2;
+ my $esc = $2;
+ $esc =~ s/\W//g;
+ push(@arr, "<li><a href=\"\#$esc\">$txt</a></li>");
+ $_ = "<a name=\"$esc\"\/><h$degree>$txt</h$degree>\n";
+ }
+
+# handles indentation within the table of contents
+ if( m/<dl( ([^>]*))?>/ ) {
+ push(@arr,"<li $2><ol>");
+ }
+
+ if( m/<\/dl>/ ) {
+ push(@arr,"</ol></li>");
+ }
+
+ push(@doc,$_);
+}
+
+my $tocElements = "";
+foreach(@arr){
+ $tocElements .= "$_\n";
+}
+my $toc = <<END;
+ <h2>Table of Contents</h2>
+ <ol>
+$tocElements
+ </ol>
+
+END
+
+foreach(@doc){
+ s/<!-- INSERT TABLE OF CONTENTS HERE -->/$toc/;
+ print $_;
+}
+
Property changes on: trunk/xspf/spec/v0/toc.pl
___________________________________________________________________
Name: svn:executable
+ *
Added: trunk/xspf/spec/v0/toc2.pl
===================================================================
--- trunk/xspf/spec/v0/toc2.pl 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/toc2.pl 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,42 @@
+#!/usr/bin/perl
+
+# name all dt elements and compile a table of contents based on them
+
+my @doc = ();
+my @arr = ();
+while(<STDIN>){
+
+ if( m/<dt( [^>]*)?>([^<]*)<\/dt>/ ){
+ push(@arr, "<li><a href=\"\#$2\">$2</a></li>");
+ s/$2/<a name="$2"\/>$2/;
+ }
+
+# handles indentation within the table of contents
+ if( m/<dl( ([^>]*))?>/ ) {
+ push(@arr,"<li $2><ol>");
+ }
+
+ if( m/<\/dl>/ ) {
+ push(@arr,"</ol></li>");
+ }
+
+ push(@doc,$_);
+}
+
+my $tocElements = "";
+foreach(@arr){
+ $tocElements .= "$_\n";
+}
+my $toc = <<END;
+ <h2>Table of Contents</h2>
+ <ol>
+$tocElements
+ </ol>
+
+END
+
+foreach(@doc){
+ s/<!-- INSERT TABLE OF CONTENTS HERE -->/$toc/;
+ print $_;
+}
+
Added: trunk/xspf/spec/v0/xspf-design-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-design-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-design-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,88 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>Notes on the XSPF playlist format</title>
+ </head>
+ <body>
+
+ <dl>
+
+ <dt>Notes on the XSPF playlist format</dt>
+ <dd>
+ <dl>
+
+ <dt>Abstract</dt>
+
+ <dd>
+ <p>This document is an informal explanation of the XSPF
+ playlist format. It is intended to explain what we did
+ and why we did it. See <a
+ href="http://xspf.org">xspf.org</a> for formal
+ documentation.</p>
+ </dd>
+
+ <dt>Administrative notes</dt>
+ <dd>
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+
+ <p>Creation date of this document is Sunday, July 18, 2004.</p>
+
+ <p>The home of this document on the web is <a
+ href="http://gonze.com/xspf/xspfdesign.html">http://gonze.com/xspf/xspfdesign.html</a></p>
+ </dd>
+
+ <dt>What is XSPF?</dt>
+ <dd>
+ <p>XSPF is an XML playlist format. It is an acronym which
+ stands for XML Shareable Playlist Format. The acronym may
+ be pronounced "spiff" or "spliff". </p>
+ </dd>
+
+ <dt>Why XSPF?</dt>
+ <dd>
+
+ <p>Assuming -- arrogantly, as I have to -- that XSPF is good
+ enough, before XSPF there was no SGML-like format for
+ playlists that could measure up to the standards of the
+ SGML-like formats for web pages (HTML), weblogs (RSS), and
+ web graphs (RDF).</p>
+
+ <p>It was evident that there was a need for an XML format.
+ XML is the preferred data description language of the
+ moment. The tools and skills to use it are ubiquitous. New
+ XML playlist formats pop up on a regular basis.</p>
+
+ <p>It was also evident that existing playlist formats fell
+ short. ASX (for Windows Media Player) and the iTunes
+ library format are proprietary. M3U, RAM, and QuickTime are
+ not SGML-like. Gnomoradio RDF is a one-man project without
+ the resources to go all the way. SMIL is too hard to
+ implement. The timing model of RSS doesn't fit audio and
+ video. Forcing timing models into HTML, as HTML+Time does,
+ creates an unintelligible feature set. Few of these formats
+ are well documented. Few make simple features easy and hard
+ features possible. Only one is an open standard. Not a
+ single one offers interoperability across major vendors.
+ Not a single one attempts to solve these problems.</p>
+
+ </dd>
+
+ <dt>Who is involved?</dt>
+ <dd><p>There are representatives from two major technology
+ vendors who needed a well-made XML playlist format for
+ commercial reasons. There is one person from the W3C whose
+ motivation was, I think, to offer the benefit of experience in
+ the standards process. There are three hackers from the free
+ and open source community whose motivation is to fix something
+ which is broken. The hackers -- myself, Robert Kaye, and
+ Matthias Freidrich -- have done the bulk of work.</p></dd>
+
+ </dl><!-- close h2 level -->
+
+ </dd>
+ </dl><!-- close h1 level -->
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-design.html
===================================================================
--- trunk/xspf/spec/v0/xspf-design.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-design.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,68 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>Notes on the XSPF playlist format</h1>
+
+ <h2>Abstract</h2>
+
+ <p>This document is an informal explanation of the XSPF playlist format. It is intended to explain the problems, goals, and decisions that went into the group. See <a href="http://xspf.org">XSPF.org</a> for formal documentation.</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p></p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, July 18, 2004.</p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Introduction</h2>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-2.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-2.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-2.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,315 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which stands for "XML
+ Shareable Playlist Format". "XSPF" can be pronounced "spiff".</p>
+
+ The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans content to your friend
+ and have it be usable. Existing formats lacked a number of features needed to make
+ this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to existing standards.
+ For example, no important playlist format declares a namespace.</li>
+ </ol>
+
+ <h2>Publication Status and authorship</h2>
+ <p>This is an informal document not associated with any standards body. It may become
+ a formal document, but for the moment it is intended to be clear and readable rather
+ than conformant with existing standards for such documents.</p>
+ <p>The home of our working group is a Wiki at <a
+ href="http://playlist.musicbrainz.org/playlist/moin.cgi">http://playlist.musicbrainz.org/playlist/moin.cgi</a>;
+ we are in the process of moving to <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+ <p>The primary author of this document is <a href="http://gonze.com">Lucas Gonze</a>.
+ Creation date of this document is Sunday, May 9, 2004.</p>
+
+ <h2>Example</h2>
+ A very simple playlist looks like this:
+ <p class="example"><?xml version="1.0" encoding="UTF-8"?>
+<playlist xmlns = "http://playlist.musicbrainz.org/playlist/moin.cgi/FrontPage/">
+ <trackList>
+ <track><location>file:///mp3s/Yo La Tengo/And Then Nothing Turned Itself Inside-Out</location>
+ <track><location>file:///mp3s/Yo La Tengo/Genius + Love = Yo La Tengo (Disc 2)</location>
+ <track><location>file:///mp3s/Yo La Tengo/I Can Hear The Heart Beating As One</location>
+ <track><location>file:///mp3s/Yo La Tengo/Nuclear War</location>
+ <track><location>file:///mp3s/Yo La Tengo/Summer Sun</location>
+ </trackList>
+</playlist></p>
+
+ <h2>Element Definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>namespace</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URN 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. playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URN for this playlist. playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URN. playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URN of an image to display in the absence of a
+ //playlist/trackList/image element. playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URN of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URNs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+</attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource type.</dd>
+ </dl>
+ <p>URN of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URN 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://playlist/trackList/track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be a hash or other
+ location-independent name, such as a MusicBrainz identifier like
+ http://musicbrainz.org/track/28af4859-5f9e-483f-8ff3-3dc1e5a6f19d.
+ MUST be a legal URN. xspf:playlist elements MAY contain zero or
+ more identifier elements.</dd>
+ <dt>info</dt>
+ <dd>URN of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URN of an image to display for the duration of the track.
+ xspf://playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf://playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf://playlist/trackList/track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf://playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf://playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf://playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf://playlist/trackList/track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf://playlist/trackList/track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource type.</dd>
+ </dl>
+ <p>URN of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf://playlist/trackList/track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="recipes"/>
+<h2>Recipes</h2>
+
+<dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <!-- template for recipes
+ <dt><a name=""></dt>
+ <dd></dd>
+ -->
+
+</dl>
+
+<h2>Administrative</h2>
+
+<p><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-2.html">Validate HTML</a></p><p><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-2.html">Validate CSS</a></p>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-2.html.1
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-2.html.1 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-2.html.1 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,301 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which stands for "XML
+ Shareable Playlist Format". "XSPF" can be pronounced "spiff".</p>
+
+ The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans content to your friend
+ and have it be usable. Existing formats lacked a number of features needed to make
+ this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to existing standards.
+ For example, no important playlist format declares a namespace.</li>
+ </ol>
+
+ <h2>Publication Status and authorship</h2>
+ <p>This is an informal document not associated with any standards body. It may become
+ a formal document, but for the moment it is intended to be clear and readable rather
+ than conformant with existing standards for such documents.</p>
+ <p>The home of our working group is a Wiki at <a
+ href="http://playlist.musicbrainz.org/playlist/moin.cgi">http://playlist.musicbrainz.org/playlist/moin.cgi</a>;
+ we are in the process of moving to <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+ <p>The primary author of this document is <a href="http://gonze.com">Lucas Gonze</a>.
+ Creation date of this document is Sunday, May 9, 2004.</p>
+
+ <h2>Example</h2>
+ A very simple playlist looks like this:
+ <p class="example"><?xml version="1.0" encoding="UTF-8"?>
+<playlist xmlns = "http://playlist.musicbrainz.org/playlist/moin.cgi/FrontPage/">
+ <trackList>
+ <track><location>file:///mp3s/Yo+La+Tengo/And+Then+Nothing+Turned+Itself+Inside-Out</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Genius+%2B+Love+%3D+Yo+La+Tengo+%28Disc+2%29</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/I+Can+Hear+The+Heart+Beating+As+One</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Nuclear+War</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Summer+Sun</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element Definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>namespace</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URN of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URN for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URN. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URN of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URN of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URNs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+</attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource type.</dd>
+ </dl>
+ <p>URN of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URN 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.
+ //playlist/trackList/track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be a hash or other
+ location-independent name, such as a MusicBrainz identifier like
+ http://musicbrainz.org/track/28af4859-5f9e-483f-8ff3-3dc1e5a6f19d.
+ MUST be a legal URN. xspf:playlist elements MAY contain zero or
+ more identifier elements.</dd>
+ <dt>info</dt>
+ <dd>URN of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URN of an image to display for the duration of the track.
+ //playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ //playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. //playlist/trackList/track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ //playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ //playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ //playlist/trackList/track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. //playlist/trackList/track elements
+ MAY contain exactly one.</dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="recipes"/>
+<h2>Recipes</h2>
+
+<dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name="m3u">How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="html">How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="smil">How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="sblx">How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+
+
+ <!-- template for recipes
+ <dt><a name=""></dt>
+ <dd></dd>
+ -->
+
+</dl>
+
+<h2>Administrative</h2>
+
+<p><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-2.html">Validate HTML</a></p><p><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-2.html">Validate CSS</a></p>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-3.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-3.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-3.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,365 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or perhaps "spliff."</p>
+
+ The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to scale down well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF had well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+
+ <h2>Publication Status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a> with help from members of the XSPF WG including Matthias Friedrich.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 4, 2004.</p>
+
+ <h2>Example</h2>
+ A very simple playlist looks like this:
+ <p class="example"><?xml version="1.0" encoding="UTF-8"?>
+<playlist xmlns = "http://playlist.musicbrainz.org/playlist/moin.cgi/FrontPage/">
+ <trackList>
+ <track><location>file:///mp3s/Yo+La+Tengo/And+Then+Nothing+Turned+Itself+Inside-Out</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Genius+%2B+Love+%3D+Yo+La+Tengo+%28Disc+2%29</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/I+Can+Hear+The+Heart+Beating+As+One</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Nuclear+War</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Summer+Sun</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element Definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>namespace</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+</attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="recipes"/>
+<h2>Recipes</h2>
+
+<dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name="m3u">How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="html">How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="smil">How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="sblx">How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+
+
+ <!-- template for recipes
+ <dt><a name=""></dt>
+ <dd></dd>
+ -->
+
+</dl>
+
+<h2>Administrative</h2>
+
+<h3>Todo list</h3>
+
+<ol>
+ <li>Table of contents.</li>
+ <li>XSLT-friendly formatting, to allow for reformatting.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Named anchors for elements.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG members.</li>
+ <li></li>
+</ol>
+
+<p><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-2.html">Validate HTML</a></p><p><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-2.html">Validate CSS</a></p>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-4-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-4-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-4-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,482 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt>User agents</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ </dl>
+
+
+ <dl>
+
+ <dt>Usecases</dt>
+ <dd></dd>
+
+ <dt>Requirements</dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt>Features</dt>
+ <dd></dd>
+
+ <dt>Principles</dt>
+ <dd>
+
+ <dl>
+
+ <dt>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt>Fuzzy names</dt>
+ <dd></dd>
+
+ <dt>Content resolvers</dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ </ol>
+ </dd>
+
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-4.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-4.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-4.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,579 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#Abstract">Abstract</a></li>
+<li><a href="#Publication status and authorship">Publication status and authorship</a></li>
+<li><a href="#Introduction">Introduction</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Element definitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#How to I convert XSPF to M3U?">How to I convert XSPF to M3U?</a></li>
+<li><a href="#How to I convert XSPF to HTML?">How to I convert XSPF to HTML?</a></li>
+<li><a href="#How to I convert XSPF to SMIL?">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#How to I convert XSPF to Soundblox?">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#How do I customize XSPF? Should I use namespaces?">How do I customize XSPF? Should I use namespaces?</a></li>
+</ol></li>
+<li><a href="#Design and architecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#User agents">User agents</a></li>
+</ol></li>
+<li ><ol>
+<li><a href="#Usecases">Usecases</a></li>
+<li><a href="#Requirements">Requirements</a></li>
+<li><a href="#Features">Features</a></li>
+<li><a href="#Principles">Principles</a></li>
+<li ><ol>
+<li><a href="#Catalogs vs. [[fixme: ??]]">Catalogs vs. [[fixme: ??]]</a></li>
+<li><a href="#Fuzzy names">Fuzzy names</a></li>
+<li><a href="#Content resolvers">Content resolvers</a></li>
+</ol></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Todo list">Todo list</a></li>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="duration"/>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name="How to I convert XSPF to M3U?"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to HTML?"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to SMIL?"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to Soundblox?"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt><a name="How do I customize XSPF? Should I use namespaces?"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="User agents"/>User agents</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ </dl>
+
+
+ <dl>
+
+ <dt><a name="Usecases"/>Usecases</dt>
+ <dd></dd>
+
+ <dt><a name="Requirements"/>Requirements</dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt><a name="Features"/>Features</dt>
+ <dd></dd>
+
+ <dt><a name="Principles"/>Principles</dt>
+ <dd>
+
+ <dl>
+
+ <dt><a name="Catalogs vs. [[fixme: ??]]"/>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt><a name="Fuzzy names"/>Fuzzy names</dt>
+ <dd></dd>
+
+ <dt><a name="Content resolvers"/>Content resolvers</dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt><a name="Todo list"/>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ </ol>
+ </dd>
+
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-5-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-5-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-5-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,454 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <dl>
+ <dt class="header2">Abstract</dt>
+ <dd>
+
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ </dd>
+
+ <dt class="header2">Publication status and authorship</dt>
+ <dd>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ </dd>
+
+ <dt class="header2">Introduction</dt>
+ <dd>
+
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ </dd>
+
+ <dt class="header2">Example</dt>
+ <dd>
+
+ A very simple document looks like this:
+ <p class="example">
+ <?xml version="1.0" encoding="UTF-8"?>
+ <playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo+La+Tengo/And+Then+Nothing+Turned+Itself+Inside-Out</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Genius+%2B+Love+%3D+Yo+La+Tengo+%28Disc+2%29</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/I+Can+Hear+The+Heart+Beating+As+One</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Nuclear+War</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Summer+Sun</location></track>
+ </trackList>
+ </playlist></p>
+
+ </dd>
+ <dt class="header2">Element definitions</dt>
+ <dd>
+
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2">Recipes</dt>
+ <dd>
+
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2">Design and architecture</dt>
+ <dd>
+
+
+ <dl>
+
+ <dt>Usecases</dt>
+ <dd></dd>
+
+ <dt>Requirements</dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt>Features</dt>
+ <dd></dd>
+
+ <dt>Principles</dt>
+ <dd>
+
+ <dl>
+
+ <dt>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt>Fuzzy names</dt>
+ <dd></dd>
+
+ <dt>Content resolvers</dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2">Administrative</dt>
+ <dd>
+
+
+ <dl>
+
+ <dt>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ </ol>
+ </dd>
+
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-2.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-2.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+ </dd>
+ </dl>
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-5.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-5.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-5.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,555 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <dl>
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ </dd>
+
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li ><ol>
+<li><a href="#Abstract">Abstract</a></li>
+<li><a href="#Publication status and authorship">Publication status and authorship</a></li>
+<li><a href="#Introduction">Introduction</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Element definitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li ><ol>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#How to I convert XSPF to M3U?">How to I convert XSPF to M3U?</a></li>
+<li><a href="#How to I convert XSPF to HTML?">How to I convert XSPF to HTML?</a></li>
+<li><a href="#How to I convert XSPF to SMIL?">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#How to I convert XSPF to Soundblox?">How to I convert XSPF to Soundblox?</a></li>
+</ol></li>
+</ol></li>
+<li ><ol>
+<li><a href="#Design and architecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#Usecases">Usecases</a></li>
+<li><a href="#Requirements">Requirements</a></li>
+<li><a href="#Features">Features</a></li>
+<li><a href="#Principles">Principles</a></li>
+<li ><ol>
+<li><a href="#Catalogs vs. [[fixme: ??]]">Catalogs vs. [[fixme: ??]]</a></li>
+<li><a href="#Fuzzy names">Fuzzy names</a></li>
+<li><a href="#Content resolvers">Content resolvers</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li ><ol>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Todo list">Todo list</a></li>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+</ol></li>
+
+ </ol>
+
+
+
+ </dd>
+
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ </dd>
+
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+ A very simple document looks like this:
+ <p class="example">
+ <?xml version="1.0" encoding="UTF-8"?>
+ <playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo+La+Tengo/And+Then+Nothing+Turned+Itself+Inside-Out</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Genius+%2B+Love+%3D+Yo+La+Tengo+%28Disc+2%29</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/I+Can+Hear+The+Heart+Beating+As+One</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Nuclear+War</location></track>
+ <track><location>file:///mp3s/Yo+La+Tengo/Summer+Sun</location></track>
+ </trackList>
+ </playlist></p>
+
+ </dd>
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+ <dl>
+ <dt><a name=""/></dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>1.0</dd>
+ <dt><a name=""/></dt>
+ <dd>utf-8</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name=""/></dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name=""/></dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name=""/></dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name=""/></dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name=""/></dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt><a name=""/></dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name=""/></dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name=""/></dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name=""/></dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name=""/></dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name=""/></dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name=""/></dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name=""/></dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+
+ <dl>
+
+ <dt><a name=""/>?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name=""/>?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name=""/>?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name=""/>?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name=""/>?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+
+ <dl>
+
+ <dt><a name=""/></dt>
+ <dd></dd>
+
+ <dt><a name=""/></dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt><a name=""/></dt>
+ <dd></dd>
+
+ <dt><a name=""/></dt>
+ <dd>
+
+ <dl>
+
+ <dt>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt><a name=""/></dt>
+ <dd></dd>
+
+ <dt><a name=""/></dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ </dd>
+ </dl>
+ <dl>
+ <dt class="header2"><a name=""/></dt>
+ <dd>
+
+
+ <dl>
+
+ <dt><a name=""/></dt>
+ <dd>
+ <ol>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ </ol>
+ </dd>
+
+ <dt><a name=""/></dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-2.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-2.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+ </dd>
+ </dl>
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-6-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-6-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-6-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,483 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no
+ owner, like M3U, or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt>User agents</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ </dl>
+
+
+ <dl>
+
+ <dt>Usecases</dt>
+ <dd></dd>
+
+ <dt>Requirements</dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt>Features</dt>
+ <dd></dd>
+
+ <dt>Principles</dt>
+ <dd>
+
+ <dl>
+
+ <dt>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt>Fuzzy names</dt>
+ <dd></dd>
+
+ <dt>Content resolvers</dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ <li>Redefinition of time fields, particularly duration, to milliseconds.</li>
+ </ol>
+ </dd>
+
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-6.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-6.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-6.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,579 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#Abstract">Abstract</a></li>
+<li><a href="#Publication status and authorship">Publication status and authorship</a></li>
+<li><a href="#Introduction">Introduction</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Element definitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#How to I convert XSPF to M3U?">How to I convert XSPF to M3U?</a></li>
+<li><a href="#How to I convert XSPF to HTML?">How to I convert XSPF to HTML?</a></li>
+<li><a href="#How to I convert XSPF to SMIL?">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#How to I convert XSPF to Soundblox?">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#How do I customize XSPF? Should I use namespaces?">How do I customize XSPF? Should I use namespaces?</a></li>
+</ol></li>
+<li><a href="#Design and architecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#User agents">User agents</a></li>
+</ol></li>
+<li ><ol>
+<li><a href="#Usecases">Usecases</a></li>
+<li><a href="#Requirements">Requirements</a></li>
+<li><a href="#Features">Features</a></li>
+<li><a href="#Principles">Principles</a></li>
+<li ><ol>
+<li><a href="#Catalogs vs. [[fixme: ??]]">Catalogs vs. [[fixme: ??]]</a></li>
+<li><a href="#Fuzzy names">Fuzzy names</a></li>
+<li><a href="#Content resolvers">Content resolvers</a></li>
+</ol></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Todo list">Todo list</a></li>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no owner, like M3U,
+ or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="duration"/>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name="How to I convert XSPF to M3U?"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to HTML?"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to SMIL?"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to Soundblox?"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt><a name="How do I customize XSPF? Should I use namespaces?"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="User agents"/>User agents</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ </dl>
+
+
+ <dl>
+
+ <dt><a name="Usecases"/>Usecases</dt>
+ <dd></dd>
+
+ <dt><a name="Requirements"/>Requirements</dt>
+ <dd>[[fixme: clean up and incorporate the requirements list from the wiki]]</dd>
+
+ <dt><a name="Features"/>Features</dt>
+ <dd></dd>
+
+ <dt><a name="Principles"/>Principles</dt>
+ <dd>
+
+ <dl>
+
+ <dt><a name="Catalogs vs. [[fixme: ??]]"/>Catalogs vs. [[fixme: ??]]</dt>
+ <dd></dd>
+
+ <dt><a name="Fuzzy names"/>Fuzzy names</dt>
+ <dd></dd>
+
+ <dt><a name="Content resolvers"/>Content resolvers</dt>
+ <dd></dd>
+
+ </dl>
+
+ </dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt><a name="Todo list"/>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ </ol>
+ </dd>
+
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-7-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-7-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-7-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,454 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no
+ owner, like M3U, or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+ <?xml version="1.0" encoding="UTF-8"?>
+ <playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+ </playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt>Content resolver</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt>Fuzzy names</dt>
+ <dd></dd>
+
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ <li>Redefinition of time fields, particularly duration, to milliseconds.</li>
+ </ol>
+ </dd>
+
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-7.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-7.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-7.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,541 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>Abstract</h2>
+ <p>This document describes a playlist format named "XSPF", which
+ stands for "XML Shareable Playlist Format". "XSPF" can be
+ pronounced "spiff" or maybe "spliff."</p>
+
+ <h2>Publication status and authorship</h2>
+
+ <p>This is an informal document not associated with any standards
+ body. It is intended to be clear and readable rather than
+ conformant with existing standards for such documents.</p>
+
+ <p>This is the fourth draft of this document. It is a major
+ rewrite, and there are a number of areas where the result is
+ rough. This document assumes that your browser supports CSS
+ reasonably well; versions of Internet Explorer older than
+ version 6 don't. Items marked like [[fixme: this]] are markers
+ for work yet to be done. See <a href="#Todo list">the todo
+ list</a> for more details about this document.</p>
+
+ <p>The home of our working group is <a href="http://xspf.org">http://xspf.org</a>. On
+ IRC, we use #playlist on irc.freenode.net. There are perhaps six regular
+ contributors, with another six commenting from time to time. Contributors came from
+ two major audio software vendors, a major weblog aggregator, the W3C, and two
+ significant .org sites related to music. We worked in the skunkworks style and were
+ not sponsored by any organization or standards body. Our purpose was to engineer a
+ high-quality design rather than to create normative requirements for
+ interoperability.</p>
+
+ <p>This document is maintained by <a href="http://gonze.com">Lucas Gonze</a>.</p>
+ <p>Creation date of this document is Sunday, May 9, 2004. The most recent edit is July 11, 2004.</p>
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#Abstract">Abstract</a></li>
+<li><a href="#Publication status and authorship">Publication status and authorship</a></li>
+<li><a href="#Introduction">Introduction</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Element definitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Design and architecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#User agents">User agents</a></li>
+<li><a href="#Fuzzy names">Fuzzy names</a></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#How to I convert XSPF to M3U?">How to I convert XSPF to M3U?</a></li>
+<li><a href="#How to I convert XSPF to HTML?">How to I convert XSPF to HTML?</a></li>
+<li><a href="#How to I convert XSPF to SMIL?">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#How to I convert XSPF to Soundblox?">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#How do I customize XSPF? Should I use namespaces?">How do I customize XSPF? Should I use namespaces?</a></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Todo list">Todo list</a></li>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+ <h2>Introduction</h2>
+
+ <p>The genesis of this project came from the mutual recognition that the quality of
+ playlist formats fell far below the normal standard for hypertext document types like
+ HTML, RDF and Atom. Our goals were to create a playlist format that is all three of:</p>
+
+ <ol>
+ <li>Open -- existing formats are either ad-hoc standards with no
+ owner, like M3U, or proprietary, like ASX.</li>
+ <li>Portable -- you should be able to send a playlist sans
+ content to your friend, or open the same playlist with
+ different software on the same machine, and have it be
+ usable. Existing formats lack a number of features needed to
+ make this work well.</li>
+ <li>Well made -- there is a glaring lack of craftsmanship to
+ existing formats. For example, no dominant playlist format
+ declares a namespace. And while there are independent efforts
+ to write a format with a high level of craftsmanship, the
+ Gnomoradio format for example, writing data formats is too
+ hard to succeed without a team.</li>
+ </ol>
+
+ <p>Over the course of our work we also realized that the format
+ had to <em>scale down</em> well. The dominant playlist format is M3U,
+ which is just a flat listing of song paths, and many developers
+ are satisfied enough to stick with it. SMIL is all three of
+ open, portable and well made, but is too complex for many needs;
+ simple SMIL playlists are not simple to implement. Similarly,
+ RDF offered well made solutions to many problems we faced, but RDF
+ tools are never trivial (as of this writing). We went to great
+ lengths to make trivial playlists trivial to implement.</p>
+
+ <p>The most pressing question for software developers is <em>why
+ should I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS? Why
+ does the world need yet another XML playlist format? The answer
+ is <em>XSPF is by far the most carefully crafted XML playlist
+ format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+ <?xml version="1.0" encoding="UTF-8"?>
+ <playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+ </playlist></p>
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example"><attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="duration"/>duration</dt>
+ <dd>Number giving the length of the media. This value is primarily
+ for fuzzy lookups, though a user-agent may display it. A user-agent
+ MUST NOT use this value to determine the rendering duration, since
+ the data will likely be low quality. The exact format of this value
+ is still under discussion. xspf:track elements
+ MAY contain exactly one.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="User agents"/>User agents</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt><a name="Fuzzy names"/>Fuzzy names</dt>
+ <dd></dd>
+
+ </dl>
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt><a name="How to I convert XSPF to M3U?"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to HTML?"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to SMIL?"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="How to I convert XSPF to Soundblox?"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2sblx.xsl">xspf2sblx.xsl</a> stylesheet.</dd>
+ <dt><a name="How do I customize XSPF? Should I use namespaces?"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt><a name="Todo list"/>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Need to get the one big normative requirement in
+ somewhere: if a resource is not playable, a player must not
+ stop processing; graceful recovery from failure.</li>
+ <li>Architectural notes on fuzzy search, catalogs, and content resolvers.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Solicit feedback on formatting of this document.</li>
+ <li>Section to tell developers why they should support XSPF.</li>
+ <li>Names of WG contributors.</li>
+ <li>Redefinition of time fields, particularly duration, to milliseconds.</li>
+ </ol>
+ </dd>
+
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-4.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-4.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-8-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-8-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-8-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,761 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+a {
+display: inline;
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+.example {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+.example:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>What is XSPF?</h2>
+
+ <p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+
+ <p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format are
+ proprietary. M3U, RAM, and M4U are flat files; QuickTime is
+ binary; Pls is in the Windows .ini format; Gnomoradio RDF is
+ RDF, not XML. SMIL is too hard to implement. The timing model
+ of RSS doesn't fit audio and video. Forcing timing models into
+ HTML, as HTML+Time does, creates an unintelligible feature set.
+ Few of these formats are well documented. None of these formats
+ make simple features easy to code and hard features possible.
+ Only one is an open standard. Not a single one offers
+ interoperability across major vendors. Not a single one
+ attempts to solve these problems.</p>
+
+ <p>The pressing question for software developers is <em>why should
+ I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS?
+ Why does the world need yet another XML playlist format? The
+ answer is <em>XSPF is by far the most carefully crafted XML
+ playlist format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <p class="example">
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/Nuclear%20War/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></p>
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Administrative notes</h2>
+
+ <p>The home of our working group is <a
+ href="http://xspf.org">http://xspf.org</a>. Members include
+ Dave Brown and Ian Rogers of Yahoo; Dan Brickley from the W3C;
+ Kevin Marks of Technorati; Matthias Freidrich and Robert Kaye of
+ MusicBrainz; and myself.</p>
+
+ <p>This author of this document is <a
+ href="http://gonze.com">Lucas Gonze</a>. Our group started work
+ in the winter of 2004. The first draft of this document was
+ May 9, 2004, the most recent was August 7, 2004.</p>
+
+ <p>In a few places in this document I will use the term MUST in
+ all caps, which will remind some readers of formal standards.
+ In this document the term should be interpreted to mean that
+ something shouted is important. XSPF is not a standard, it is
+ an ad-hoc project by a group of individuals.</p>
+
+ <h2>Abstractions</h2>
+
+ <dl>
+
+ <dt>Defining playlists</dt><!-- first child of abstractions -->
+ <dd>
+ <p>An XSPF playlist describes a sequence of objects to
+ be rendered. Objects might be audio, video, text,
+ playlists, or any other media type. The function of a
+ playlist is to identify the objects and communicate
+ their order.</p>
+ </dd><!-- first child of abstractions -->
+
+ <dt>What a playlist is not</dt><!-- first child of abstractions -->
+ <dd>
+ <p>The function of a playlist <em>is not</em> to
+ communicate metadata about the composer, song title,
+ etc. Metadata is hard and there are many providers
+ already. We decided that we couldn't compete, and
+ that there was no need for us to try. Moreover, good
+ metadata does not travel well -- every user has to
+ recreate it. Metadata should come from external
+ sources and namespaces like MusicBrainz or Gracenote;
+ this what the XSPF <span class="elem">link</span>
+ and <span class="elem">meta</span> elements are
+ for.</p>
+
+ <p>The function of a playlist <em>is not</em> to store
+ derived information about objects that a user has a
+ copy of. A playlist is not a catalog. A catalog is
+ computed across hard data like files; it stores
+ information like filesystem paths and the contents of
+ ID3 tags. This data has no value on any machine but
+ the one on which it originated. Sharing this data
+ would be a privacy and security violation. Software
+ which needs access to this data has no reason to
+ maintain it in a standard format, because it has no
+ reason to allow access to it. Standardizing this data
+ would be fruitless, because there are an endless
+ number of measurements that software might take and
+ store. Derived information belongs in
+ a <em>catalog</em>.</p>
+
+ <p>Things a playlist is not, then, are a metadata format or a
+ catalog. We took care to enable these features, but also to
+ avoid duplicating their functionality, poorly.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ <dt>Shareability</dt><!-- first child of abstractions -->
+ <dd>
+
+ <p>If there is no reason for a playlist to be shared, there is
+ no need for a new format. Even a buggy format does no
+ damage if it is created and consumed by the same software on
+ the same machine. The need for a new format only comes up
+ when a playlist travels from one machine to another, for
+ example when it is published on the internet.</p>
+
+ <p>One type of shareability is between different pieces of
+ software on the same machine. It is common for playlists
+ created with one application to not be usable by another
+ application on the same machine because of different or
+ conflicting interpretations of the playlist format. M3U
+ suffers from this very badly, because M3U playlists often
+ reference files according to a base path which changes from
+ application to application. The XSPF group aimed to fix this
+ by providing unambiguous definitions.</p>
+
+ <p>The other type of shareability is between different
+ machines. For playlists to be meaningful on different
+ machines, they must be able to identify network resources.
+ Audio and video objects are often abstractions like "movie X
+ by director Y" rather than computer-friendly objects like
+ "whatever file can be gotten from the URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ </dl><!-- end abstractions -->
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt>license</dt>
+ <dd>URI of a resource that describes the license under which this playlist
+ was released.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <p class="example">
+<attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></p>
+ </dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered. xspf:track
+ elements MUST be rendered in the order in which they appear, from top to
+ bottom, unless a different ordering is otherwise indicated. If an
+ xspf:track element cannot be rendered, a user-agent MUST skip to the next
+ xspf:track element and MUST NOT interrupt the sequence.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</dd>
+
+ <dt>duration</dt>
+
+ <dd>The time to render a resource, in
+ milliseconds. It MUST be a valid <a
+ href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value is
+ only a hint -- different XSPF generators will
+ generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <p class="example"><meta rel="http://example.org/key">value</meta></p>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt>Content resolver</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt>Fuzzy names</dt>
+ <dd>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, filesystem
+ paths and secure hashes, but also for query-based identifiers --
+ free text fields like artist and work title and numeric fields
+ for song length, all of which together should be enough for a
+ good content resolver to turn into files.
+ </dd>
+
+ </dl>
+
+ <h2>Requirements for XSPF players</h2>
+ <dl><!-- begin requirements -->
+ <dt>Graceful failure</dt><!-- first child of normative -->
+ <dd>
+ <p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+ <p></p>
+ </dd>
+
+ <dt>Relative paths</dt><!-- first child of normative -->
+ <dd>
+ <p>Relative paths MUST be resolved according to the <a
+ href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a
+ href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ </dl><!-- end requirements -->
+
+ <h2>Usecases for playlists</h2>
+
+ <dl>
+
+ <dt>Flag player application</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+
+ <p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+
+ <p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Allow streaming</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+
+ <p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+
+ <p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Collecting fragmented resources</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+
+ <p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+
+ <p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Alternate media types</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+
+ <p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URI within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+
+ <p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Caching derived info</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+ <p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+ <p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Metadata storage</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+ <p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+ <p>XSPF' solution: XSPF defers this functionality to
+ other sources. Metadata is hard; there are already
+ many projects to deal with it, some of which are very
+ good. Metadata is attached to an XSPF track according
+ to whatever syntax an imported vocabulary defines.
+ XML namespaces may be used, but the preferred syntax
+ is the XSPF <span class="elem">link</span> and <span
+ class="elem">meta</span> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Authoring compilations for expressive reasons</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+
+ <p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URIs, into a file in the
+ M3U format.</p>
+
+ <p>XSPF' solution: The XSPF <span
+ class="elem">trackList</span> element contains a
+ sequence of <span class="elem">track</span> elements,
+ each of which points to one of the objects.</p>
+ </dd><!-- first child of usecases -->
+
+ </dl><!-- end usecases -->
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote><i>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </i></blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</dd>
+ <dt>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ <dt>How do I validate XSPF?</dt>
+ <dd>...ryan shaw's .rnc version... http://mayhem-chaos.net/stuff/xspf-draft8.rng</dd>
+
+<!--
+How do I use MusicBrainz metadata?
+<meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+
+<track>
+<identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+<title>Smoke Two Joints</title>
+<creator>Sublime</creator>
+<duration>175466</duration>
+<meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+
+-->
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+
+ <dt>Todo list</dt>
+ <dd>
+ <ol>
+ <li>Table of contents is still whacky.</li>
+ <li>Bug and issue list for XSPF.</li>
+ <li>Contact address for bugs in this document and in XSPF.</li>
+ <li>Spell check.</li>
+ <li>Get a third party to be an editor.</li>
+ <li>Define cardinality of elements. See Matthias' list.</li>
+ </ol>
+ </dd>
+
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-8.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-8.html">CSS</a></li>
+ </ol>
+ </dd>
+
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-8.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-8.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-8.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,910 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+blockquote {
+font-style: italic;
+}
+
+a {
+display: inline;
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+pre {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+pre:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+<a name="WhatisXSPF"/><h2>What is XSPF?</h2>
+
+ <p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+
+ <p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format are
+ proprietary. ASX resembles XML in that it uses angle brackets,
+ but is not XML by any means. M3U, RAM, and M4U are flat files;
+ QuickTime is binary; Pls is in the Windows .ini format;
+ Gnomoradio RDF is RDF, not XML. SMIL is too hard to implement.
+ The timing model of RSS doesn't fit audio and video. Forcing
+ timing models into HTML, as HTML+Time does, creates an
+ unintelligible feature set. Few of these formats are well
+ documented. None of these formats make simple features easy to
+ code and hard features possible. Only one is an open standard.
+ Not a single one offers interoperability across major vendors.
+ Not a single one attempts to solve these problems.</p>
+
+ <p>The pressing question for software developers is <em>why should
+ I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS?
+ Why does the world need yet another XML playlist format? The
+ answer is <em>XSPF is by far the most carefully crafted XML
+ playlist format</em>.</p>
+
+<a name="Example"/><h2>Example</h2>
+ A very simple document looks like this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+or this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>http://yolatengo.com/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>http://yolatengo.com/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>http://yolatengo.com/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>http://yolatengo.com/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>http://yolatengo.com/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#WhatisXSPF">What is XSPF?</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Administrativenotes">Administrative notes</a></li>
+<li><a href="#Abstractions">Abstractions</a></li>
+<li ><ol>
+<li><a href="#Definingplaylists">Defining playlists</a></li>
+<li><a href="#Whataplaylistisnot">What a playlist is not</a></li>
+<li><a href="#Shareability">Shareability</a></li>
+</ol></li>
+<li><a href="#Elementdefinitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Designandarchitecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#Contentresolver">Content resolver</a></li>
+<li><a href="#Fuzzynames">Fuzzy names</a></li>
+</ol></li>
+<li><a href="#RequirementsforXSPFplayers">Requirements for XSPF players</a></li>
+<li ><ol>
+<li><a href="#Gracefulfailure">Graceful failure</a></li>
+<li><a href="#Relativepaths">Relative paths</a></li>
+</ol></li>
+<li><a href="#Usecasesforplaylists">Usecases for playlists</a></li>
+<li ><ol>
+<li><a href="#Flagplayerapplication">Flag player application</a></li>
+<li><a href="#Allowstreaming">Allow streaming</a></li>
+<li><a href="#Collectingfragmentedresources">Collecting fragmented resources</a></li>
+<li><a href="#Alternatemediatypes">Alternate media types</a></li>
+<li><a href="#Cachingderivedinfo">Caching derived info</a></li>
+<li><a href="#Metadatastorage">Metadata storage</a></li>
+<li><a href="#Authoringcompilationsforexpressivereasons">Authoring compilations for expressive reasons</a></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#HowtoIconvertXSPFtoM3U">How to I convert XSPF to M3U?</a></li>
+<li><a href="#HowtoIconvertXSPFtoHTML">How to I convert XSPF to HTML?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSMIL">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSoundblox">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#HowdoIcustomizeXSPFShouldIusenamespaces">How do I customize XSPF? Should I use namespaces?</a></li>
+<li><a href="#HowdoIvalidateXSPF">How do I validate XSPF?</a></li>
+<li><a href="#HowdoIuseMusicBrainzmetadata">How do I use MusicBrainz metadata?</a></li>
+<li><a href="#HowdoIrefertoaBitTorrent">How do I refer to a BitTorrent?</a></li>
+<li><a href="#HowdoIrefertoaMagnetorsha1URI">How do I refer to a Magnet or sha1: URI?</a></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+<a name="Administrativenotes"/><h2>Administrative notes</h2>
+
+ <p>Version 0 is frozen and complete. Anybody writing code
+ according to this specification can be very confident that it will
+ not change.</p>
+
+ <p>The home of our working group is <a
+ href="http://xspf.org">http://xspf.org</a>. Members include
+ Dave Brown and Ian Rogers of Yahoo; Dan Brickley from the W3C;
+ Kevin Marks of Technorati; Matthias Freidrich and Robert Kaye of
+ MusicBrainz; Ryan Shaw of UC Berkely; and myself, from Webjay.</p>
+
+ <p>This author of this document is <a
+ href="http://gonze.com">Lucas Gonze</a>. Our group started work
+ in the winter of 2004. The first public draft of this document
+ was May 9, 2004, the most recent was January 6, 2005.</p>
+
+ <p>In a few places in this document I will use the term MUST in
+ all caps, which will remind some readers of formal standards.
+ In this document the term should be interpreted to mean that
+ something shouted is important. XSPF is not a standard, it is
+ an ad-hoc project by a group of individuals.</p>
+
+<a name="Abstractions"/><h2>Abstractions</h2>
+
+ <dl>
+
+ <dt><a name="Definingplaylists"/>Defining playlists</dt><!-- first child of abstractions -->
+ <dd>
+ <p>An XSPF playlist describes a sequence of objects to
+ be rendered. Objects might be audio, video, text,
+ playlists, or any other media type. The function of a
+ playlist is to identify the objects and communicate
+ their order.</p>
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Whataplaylistisnot"/>What a playlist is not</dt><!-- first child of abstractions -->
+ <dd>
+ <p>The function of a playlist <em>is not</em> to
+ communicate metadata about the composer, song title,
+ etc. Metadata is hard and there are many providers
+ already. We decided that we couldn't compete, and
+ that there was no need for us to try. Moreover, good
+ metadata does not travel well -- every user has to
+ recreate it. Metadata should come from external
+ sources and namespaces like MusicBrainz or Gracenote;
+ this what the XSPF <span class="elem">link</span>
+ and <span class="elem">meta</span> elements are
+ for.</p>
+
+ <p>The function of a playlist <em>is not</em> to store
+ derived information about objects that a user has a
+ copy of. A playlist is not a catalog. A catalog is
+ computed across hard data like files; it stores
+ information like filesystem paths and the contents of
+ ID3 tags. This data has no value on any machine but
+ the one on which it originated. Sharing this data
+ would be a privacy and security violation. Software
+ which needs access to this data has no reason to
+ maintain it in a standard format, because it has no
+ reason to allow access to it. Standardizing this data
+ would be fruitless, because there are an endless
+ number of measurements that software might take and
+ store. Derived information belongs in
+ a <em>catalog</em>.</p>
+
+ <p>Things a playlist is not, then, are a metadata format or a
+ catalog. We took care to enable these features, but also to
+ avoid duplicating their functionality, poorly.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Shareability"/>Shareability</dt><!-- first child of abstractions -->
+ <dd>
+
+ <p>If there is no reason for a playlist to be shared, there is
+ no need for a new format. Even a buggy format does no
+ damage if it is created and consumed by the same software on
+ the same machine. The need for a new format only comes up
+ when a playlist travels from one machine to another, for
+ example when it is published on the internet.</p>
+
+ <p>One type of shareability is between different pieces of
+ software on the same machine. It is common for playlists
+ created with one application to not be usable by another
+ application on the same machine because of different or
+ conflicting interpretations of the playlist format. M3U
+ suffers from this very badly, because M3U playlists often
+ reference files according to a base path which changes from
+ application to application. The XSPF group aimed to fix this
+ by providing unambiguous definitions.</p>
+
+ <p>The other type of shareability is between different
+ machines. For playlists to be meaningful on different
+ machines, they must be able to identify network resources.
+ Audio and video objects are often abstractions like "movie X
+ by director Y" rather than computer-friendly objects like
+ "whatever file can be gotten from the URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ </dl><!-- end abstractions -->
+
+<a name="Elementdefinitions"/><h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist in text/plain format.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URI for this playlist. xspf:playlist elements MAY contain zero
+ or more location elements.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URI. xspf:playlist elements MAY
+ contain zero or more identifier elements.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URI of a resource that describes the license under
+ which this playlist was released. xspf:playlist
+ elements may contain zero or one license element.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location element or //playlist/identifier
+ to the top of the items in the //playlist/attribution element.
+ xspf:playlist elements MAY contain exactly one xspf:attribution
+ element.</p>
+ <pre>
+<attribution>
+ <location>http://snafu.com/modified_version_of_modified_version_of_original_playlist.xspf</location>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <location>http://foo.com/original_playlist.xspf</location>
+ </attribution></pre>
+ </dd>
+
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more link elements.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more meta elements.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered.
+ The sequence is a hint, not a requirement; renderers
+ are advised to play tracks from top to bottom unless
+ there is an indication otherwise.<p/>
+
+ <p>If an xspf:track element cannot be rendered, a
+ user-agent MUST skip to the next xspf:track element
+ and MUST NOT interrupt the sequence.</p>
+
+ <p>xspf:playlist elements MUST contain one and only
+ one trackList element.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URI of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URI. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track in text/plain format.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URI of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URI of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</dd>
+
+ <dt><a name="duration"/>duration</dt>
+
+ <dd>The time to render a resource, in
+ milliseconds. It MUST be a valid <a
+ href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value is
+ only a hint -- different XSPF generators will
+ generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URI of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. MUST be valid text/plain, not
+ XML.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="Designandarchitecture"/><h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="Contentresolver"/>Content resolver</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt><a name="Fuzzynames"/>Fuzzy names</dt>
+ <dd>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, filesystem
+ paths and secure hashes, but also for query-based identifiers --
+ free text fields like artist and work title and numeric fields
+ for song length, all of which together should be enough for a
+ good content resolver to turn into files.
+ </dd>
+
+ </dl>
+
+<a name="RequirementsforXSPFplayers"/><h2>Requirements for XSPF players</h2>
+ <dl><!-- begin requirements -->
+ <dt><a name="Gracefulfailure"/>Graceful failure</dt><!-- first child of normative -->
+ <dd>
+ <p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+ <p></p>
+ </dd>
+
+ <dt><a name="Relativepaths"/>Relative paths</dt><!-- first child of normative -->
+ <dd>
+ <p>Relative paths MUST be resolved according to the <a
+ href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a
+ href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ </dl><!-- end requirements -->
+
+<a name="Usecasesforplaylists"/><h2>Usecases for playlists</h2>
+
+ <dl>
+
+ <dt><a name="Flagplayerapplication"/>Flag player application</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+
+ <p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+
+ <p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Allowstreaming"/>Allow streaming</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+
+ <p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+
+ <p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Collectingfragmentedresources"/>Collecting fragmented resources</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+
+ <p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+
+ <p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Alternatemediatypes"/>Alternate media types</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+
+ <p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URI within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+
+ <p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Cachingderivedinfo"/>Caching derived info</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+ <p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+ <p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Metadatastorage"/>Metadata storage</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+ <p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+ <p>XSPF' solution: XSPF defers this functionality to
+ other sources. Metadata is hard; there are already
+ many projects to deal with it, some of which are very
+ good. Metadata is attached to an XSPF track according
+ to whatever syntax an imported vocabulary defines.
+ XML namespaces may be used, but the preferred syntax
+ is the XSPF <span class="elem">link</span> and <span
+ class="elem">meta</span> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Authoringcompilationsforexpressivereasons"/>Authoring compilations for expressive reasons</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+
+ <p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URIs, into a file in the
+ M3U format.</p>
+
+ <p>XSPF' solution: The XSPF <span
+ class="elem">trackList</span> element contains a
+ sequence of <span class="elem">track</span> elements,
+ each of which points to one of the objects.</p>
+ </dd><!-- first child of usecases -->
+
+ </dl><!-- end usecases -->
+
+<a name="Recipes"/><h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ <dt><a name="HowtoIconvertXSPFtoM3U"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoHTML"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSMIL"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSoundblox"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</dd>
+ <dt><a name="HowdoIcustomizeXSPFShouldIusenamespaces"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ <dt><a name="HowdoIvalidateXSPF"/>How do I validate XSPF?</dt>
+ <dd><p>Robert Kaye has created a Relax NG schema for XSPF draft 8 at <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">http://mayhem-chaos.net/stuff/xspf-draft8.rng</a>. You can use <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a> to invoke it.</p>
+ <p>For users of Emacs nxml-mode, Ryan Shaw has posted a .rnc
+ version of Robert's schema at <a
+ href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html">http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html</a>.
+ This is just a matter of putting the .rnc file in the schema/
+ subdirectory of your nxml-mode installation. nxml-mode will
+ find it automatically and add it to the list of available
+ schemas; if you begin authoring an XSPF playlist, nxml-mode
+ will choose the correct schema by examining the root element
+ name.</p>
+ </dd>
+
+ <dt><a name="HowdoIuseMusicBrainzmetadata"/>How do I use MusicBrainz metadata?</dt>
+ <dd>
+ Rather than include the literal artist name, song duration, etc, for a track within a playlist, MusicBrainz gives the URL of an XML file containing these items. Assume that the MusicBrainz definition of what a track listing means is at http://musicbrainz.org/track. (There is nothing at that URL, which is fine -- the URL in an XSPF meta[@rel] attribute works the same way as the URL in an XML namespace declaration). A typical track listing has a URL like http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429.
+ <div class="example">
+<track>
+ <identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+ <title>Smoke Two Joints</title>
+ <creator>Sublime</creator>
+ <duration>175466</duration>
+ <meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+ </div>
+
+ </dd>
+
+ <dt><a name="HowdoIrefertoaBitTorrent"/>How do I refer to a BitTorrent?</dt>
+ <dd>Put the torrent file in a playlist/trackList/track/location element.</dd>
+
+ <dt><a name="HowdoIrefertoaMagnetorsha1URI"/>How do I refer to a Magnet or sha1: URI?</dt>
+ <dd>A sha1: URI is a location independent canonical ID, so it
+ belongs in a playlist/trackList/track/identifier element. A
+ Magnet URI is resolvable, so belongs in
+ playlist/trackList/track/location.</dd>
+
+ </dl>
+
+<a name="Administrative"/><h2>Administrative</h2>
+
+ <dl>
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-8.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-8.html">CSS</a></li>
+ </ol>
+ </dd>
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-9-IN.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-9-IN.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-9-IN.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,824 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+blockquote {
+font-style: italic;
+}
+
+a {
+display: inline;
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+pre {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+pre:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+ <h2>What is XSPF?</h2>
+
+ <p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+
+ <p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format are
+ proprietary. ASX resembles XML in that it uses angle brackets,
+ but is not XML by any means. M3U, RAM, and M4U are flat files;
+ QuickTime is binary; Pls is in the Windows .ini format;
+ Gnomoradio RDF is RDF, not XML. SMIL is too hard to implement.
+ The timing model of RSS doesn't fit audio and video. Forcing
+ timing models into HTML, as HTML+Time does, creates an
+ unintelligible feature set. Few of these formats are well
+ documented. None of these formats make simple features easy to
+ code and hard features possible. Only one is an open standard.
+ Not a single one offers interoperability across major vendors.
+ Not a single one attempts to solve these problems.</p>
+
+ <p>The pressing question for software developers is <em>why should
+ I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS?
+ Why does the world need yet another XML playlist format? The
+ answer is <em>XSPF is by far the most carefully crafted XML
+ playlist format</em>.</p>
+
+ <h2>Example</h2>
+ A very simple document looks like this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+or this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>http://yolatengo.com/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>http://yolatengo.com/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>http://yolatengo.com/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>http://yolatengo.com/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>http://yolatengo.com/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+
+ <a name="toc"/><!-- INSERT TABLE OF CONTENTS HERE -->
+
+ <h2>Administrative notes</h2>
+
+ <p>Version 0 is frozen and complete. Anybody writing code
+ according to this specification can be very confident that it will
+ not change.</p>
+
+ <p>The home of our working group is <a
+ href="http://xspf.org">http://xspf.org</a>. Members include
+ Dave Brown and Ian Rogers of Yahoo; Dan Brickley from the W3C;
+ Kevin Marks of Technorati; Matthias Friedrich and Robert Kaye of
+ MusicBrainz; Ryan Shaw of UC Berkely; and myself, from Webjay.</p>
+
+ <p>This author of this document is <a
+ href="http://gonze.com">Lucas Gonze</a>. Our group started work
+ in the winter of 2004. The first public draft of this document
+ was May 9, 2004, the most recent was January 6, 2005.</p>
+
+ <h3>Terminology</h3>
+
+ <p>In places in this document I will use the terms MUST, MAY and
+ SHOULD in all caps, which will remind some readers of formal
+ standards. In this document the term should be interpreted to
+ mean that something shouted is important. XSPF is not a
+ standard, it is an ad-hoc project by a group of
+ individuals.</p>
+
+ <p>The terms URI, URL, and URN should be understood as follows: a
+ URL is an address of something that can be fetched by a computer;
+ a URN is a name of something which may be purely an abstraction; a
+ URI is either.</p>
+
+ <h2>Abstractions</h2>
+
+ <dl>
+
+ <dt>Defining playlists</dt><!-- first child of abstractions -->
+ <dd>
+ <p>An XSPF playlist describes a sequence of objects to
+ be rendered. Objects might be audio, video, text,
+ playlists, or any other media type. The function of a
+ playlist is to identify the objects and communicate
+ their order.</p>
+ </dd><!-- first child of abstractions -->
+
+ <dt>What a playlist is not</dt><!-- first child of abstractions -->
+ <dd>
+ <p>The function of a playlist <em>is not</em> to
+ communicate metadata about the composer, song title,
+ etc. Metadata is hard and there are many providers
+ already. We decided that we couldn't compete, and
+ that there was no need for us to try. Moreover, good
+ metadata does not travel well -- every user has to
+ recreate it. Metadata should come from external
+ sources and namespaces like MusicBrainz or Gracenote;
+ this what the XSPF <span class="elem">link</span>
+ and <span class="elem">meta</span> elements are
+ for.</p>
+
+ <p>The function of a playlist <em>is not</em> to store
+ derived information about objects that a user has a
+ copy of. A playlist is not a catalog. A catalog is
+ computed across hard data like files; it stores
+ information like filesystem paths and the contents of
+ ID3 tags. This data has no value on any machine but
+ the one on which it originated. Sharing this data
+ would be a privacy and security violation. Software
+ which needs access to this data has no reason to
+ maintain it in a standard format, because it has no
+ reason to allow access to it. Standardizing this data
+ would be fruitless, because there are an endless
+ number of measurements that software might take and
+ store. Derived information belongs in
+ a <em>catalog</em>.</p>
+
+ <p>Things a playlist is not, then, are a metadata format or a
+ catalog. We took care to enable these features, but also to
+ avoid duplicating their functionality, poorly.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ <dt>Shareability</dt><!-- first child of abstractions -->
+ <dd>
+
+ <p>If there is no reason for a playlist to be shared, there is
+ no need for a new format. Even a buggy format does no
+ damage if it is created and consumed by the same software on
+ the same machine. The need for a new format only comes up
+ when a playlist travels from one machine to another, for
+ example when it is published on the internet.</p>
+
+ <p>One type of shareability is between different pieces of
+ software on the same machine. It is common for playlists
+ created with one application to not be usable by another
+ application on the same machine because of different or
+ conflicting interpretations of the playlist format. M3U
+ suffers from this very badly, because M3U playlists often
+ reference files according to a base path which changes from
+ application to application. The XSPF group aimed to fix this
+ by providing unambiguous definitions.</p>
+
+ <p>The other type of shareability is between different
+ machines. For playlists to be meaningful on different
+ machines, they must be able to identify network resources.
+ Audio and video objects are often abstractions like "movie X
+ by director Y" rather than computer-friendly objects like
+ "whatever file can be gotten from the URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ </dl><!-- end abstractions -->
+
+ <h2>Element definitions</h2>
+ <dl>
+ <dt>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>version</dt>
+ <dd>1.0</dd>
+ <dt>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>annotation</dt>
+ <dd>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.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt>info</dt>
+ <dd>URL of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>location</dt>
+ <dd>Source URL for this playlist. xspf:playlist elements
+ MAY contain exactly one.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URN. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt>image</dt>
+ <dd>URL of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.
+
+ <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>
+
+</dd>
+ <dt>license</dt>
+ <dd>URL of a resource that describes the license under
+ which this playlist was released. xspf:playlist
+ elements may contain zero or one license element.</dd>
+ <dt>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location 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>
+ <p>Such a list can grow without limit, so as a
+ practical matter we suggest deleting ancestors more
+ than ten generations back.</p>
+ <pre>
+<attribution>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <identifier>somescheme:original_playlist.xspf</identifier>
+ </attribution></pre>
+ </dd>
+
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more link elements.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URL of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more meta elements.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <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>
+ </dd>
+ <dt>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered.
+ The sequence is a hint, not a requirement; renderers
+ are advised to play tracks from top to bottom unless
+ there is an indication otherwise.<p/>
+
+ <p>If an xspf:track element cannot be rendered, a
+ user-agent MUST skip to the next xspf:track element
+ and MUST NOT interrupt the sequence.</p>
+
+ <p>xspf:playlist elements MUST contain one and only
+ one trackList element.</p>
+ <dl class="elements">
+ <dt>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt>location</dt>
+ <dd>URL of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URN. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>annotation</dt>
+ <dd>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.</dd>
+ <dt>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt>info</dt>
+ <dd>URL of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt>image</dt>
+ <dd>URL of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</dd>
+
+ <dt>duration</dt>
+
+ <dd>The time to render a resource, in
+ milliseconds. It MUST be a valid <a
+ href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value is
+ only a hint -- different XSPF generators will
+ generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</dd>
+ <dt>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource type.</dd>
+ </dl>
+ <p>URL of a resource.</p>
+ </dd>
+ <dt>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt>rel</dt>
+ <dd>URN of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. This is
+ character data, not HTML, and it may not
+ contain markup. xspf:playlist elements MAY
+ contain exactly one.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+ <h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt>Content resolver</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt>Fuzzy names</dt>
+ <dd>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, filesystem
+ paths and secure hashes, but also for query-based identifiers --
+ free text fields like artist and work title and numeric fields
+ for song length, all of which together should be enough for a
+ good content resolver to turn into files.
+ </dd>
+
+ </dl>
+
+ <h2>Requirements for XSPF players</h2>
+ <dl><!-- begin requirements -->
+ <dt>Graceful failure</dt><!-- first child of normative -->
+ <dd>
+ <p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+ <p></p>
+ </dd>
+
+ <dt>Relative paths</dt><!-- first child of normative -->
+ <dd>
+ <p>Relative paths MUST be resolved according to the <a
+ href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a
+ href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+
+ </dd>
+
+ </dl><!-- end requirements -->
+
+ <h2>Usecases for playlists</h2>
+
+ <dl>
+
+ <dt>Flag player application</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+
+ <p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+
+ <p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Allow streaming</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+
+ <p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+
+ <p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Collecting fragmented resources</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+
+ <p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+
+ <p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt>Alternate media types</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+
+ <p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URL within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+
+ <p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Caching derived info</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+ <p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+ <p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Metadata storage</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+ <p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+ <p>XSPF' solution: XSPF defers this functionality to
+ other sources. Metadata is hard; there are already
+ many projects to deal with it, some of which are very
+ good. Metadata is attached to an XSPF track according
+ to whatever syntax an imported vocabulary defines.
+ XML namespaces may be used, but the preferred syntax
+ is the XSPF <span class="elem">link</span> and <span
+ class="elem">meta</span> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+ </dd><!-- first child of usecases -->
+
+ <dt>Authoring compilations for expressive reasons</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+
+ <p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URLs, into a file in the
+ M3U format.</p>
+
+ <p>XSPF' solution: The XSPF <span
+ class="elem">trackList</span> element contains a
+ sequence of <span class="elem">track</span> elements,
+ each of which points to one of the objects.</p>
+ </dd><!-- first child of usecases -->
+
+ </dl><!-- end usecases -->
+
+ <h2>Recipes</h2>
+
+ <dl>
+
+ <dt>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ <dt>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</dd>
+ <dt>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ <dt>How do I validate XSPF?</dt>
+ <dd><p>Robert Kaye has created a Relax NG schema for XSPF draft 8 at <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">http://mayhem-chaos.net/stuff/xspf-draft8.rng</a>. You can use <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a> to invoke it.</p>
+ <p>For users of Emacs nxml-mode, Ryan Shaw has posted a .rnc
+ version of Robert's schema at <a
+ href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html">http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html</a>.
+ This is just a matter of putting the .rnc file in the schema/
+ subdirectory of your nxml-mode installation. nxml-mode will
+ find it automatically and add it to the list of available
+ schemas; if you begin authoring an XSPF playlist, nxml-mode
+ will choose the correct schema by examining the root element
+ name.</p>
+ </dd>
+
+ <dt>How do I use MusicBrainz metadata?</dt>
+ <dd>
+ Rather than include the literal artist name, song duration, etc, for a track within a playlist, MusicBrainz gives the URL of an XML file containing these items. Assume that the MusicBrainz definition of what a track listing means is at http://musicbrainz.org/track. (There is nothing at that URL, which is fine -- the URL in an XSPF meta[@rel] attribute works the same way as the URL in an XML namespace declaration). A typical track listing has a URL like http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429.
+ <div class="example">
+<track>
+ <identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+ <title>Smoke Two Joints</title>
+ <creator>Sublime</creator>
+ <duration>175466</duration>
+ <meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+ </div>
+
+ </dd>
+
+ <dt>How do I refer to a BitTorrent?</dt>
+ <dd>Put the torrent file in a playlist/trackList/track/location element.</dd>
+
+ <dt>How do I refer to a Magnet or sha1: URI?</dt>
+ <dd>A sha1: URI is a location independent canonical ID, so it
+ belongs in a playlist/trackList/track/identifier element. A
+ Magnet URI is resolvable, so belongs in
+ playlist/trackList/track/location.</dd>
+
+ </dl>
+
+ <h2>Administrative</h2>
+
+ <dl>
+ <dt>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-8.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-8.html">CSS</a></li>
+ </ol>
+ </dd>
+ </dl>
+
+ </body>
+</html>
Added: trunk/xspf/spec/v0/xspf-draft-9.html
===================================================================
--- trunk/xspf/spec/v0/xspf-draft-9.html 2005-02-23 01:00:12 UTC (rev 8970)
+++ trunk/xspf/spec/v0/xspf-draft-9.html 2005-02-23 01:13:10 UTC (rev 8971)
@@ -0,0 +1,935 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
+ <title>The XSPF Playlist Format, version 0</title>
+ <style type="text/css">
+ /*<![CDATA[*/
+
+body {
+font-family: Verdana, Myriad Web, Syntax, sans-serif;
+font-size: 80%;
+color: #555753;
+
+}
+
+blockquote {
+font-style: italic;
+}
+
+a {
+display: inline;
+}
+
+pre {
+margin-left: 3em;
+background-color: lightyellow;
+}
+
+h1 {
+text-align: center;
+}
+
+pre {
+background-color: lightyellow;
+font-family: courier, monospace;
+white-space: pre;
+color: #993300;
+}
+
+pre:before {
+content: "EXAMPLE: ";
+}
+
+.attributes:before {
+content: "ATTRIBUTES: ";
+}
+
+.elements:before {
+content: "ELEMENTS: ";
+}
+
+
+ /*]]>*/
+ </style>
+ </head>
+ <body>
+
+ <h1>The XSPF Playlist Format, version 0</h1>
+
+<a name="WhatisXSPF"/><h2>What is XSPF?</h2>
+
+ <p>There is no XML format for playlists that can measure up to the
+ standards of the formats for web pages (HTML), weblogs (RSS),
+ and web graphs (RDF/XML). It is evident that there is a need,
+ because XML is the preferred data description language of the
+ moment and as a result the tools and skills to use it are
+ ubiquitous.</p>
+
+ <p>It is also evident that existing playlist formats fall short.
+ ASX (for Windows Media Player) and the iTunes library format are
+ proprietary. ASX resembles XML in that it uses angle brackets,
+ but is not XML by any means. M3U, RAM, and M4U are flat files;
+ QuickTime is binary; Pls is in the Windows .ini format;
+ Gnomoradio RDF is RDF, not XML. SMIL is too hard to implement.
+ The timing model of RSS doesn't fit audio and video. Forcing
+ timing models into HTML, as HTML+Time does, creates an
+ unintelligible feature set. Few of these formats are well
+ documented. None of these formats make simple features easy to
+ code and hard features possible. Only one is an open standard.
+ Not a single one offers interoperability across major vendors.
+ Not a single one attempts to solve these problems.</p>
+
+ <p>The pressing question for software developers is <em>why should
+ I support this XML playlist format</em> instead of or in
+ addition to ASX, SMIL, Gnomoradio RDF, iTunes XML, or RSS?
+ Why does the world need yet another XML playlist format? The
+ answer is <em>XSPF is by far the most carefully crafted XML
+ playlist format</em>.</p>
+
+<a name="Example"/><h2>Example</h2>
+ A very simple document looks like this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>file:///mp3s/Yo%20La%20Tengo/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+or this:
+ <pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<playlist version="0" xmlns = "http://xspf.org/ns/0/">
+ <trackList>
+ <track><location>http://yolatengo.com/1_Nuclear%20War%20Version%201.mp3</location></track>
+ <track><location>http://yolatengo.com/2_Nuclear%20War%20Version%202.mp3</location></track>
+ <track><location>http://yolatengo.com/3_Nuclear%20War%20Version%203.mp3</location></track>
+ <track><location>http://yolatengo.com/4_Nuclear%20War%20Version%204</location></track>
+ <track><location>http://yolatengo.com/5_Nuclear%20War%20Version%204%20(Mike%20Ladd%20Remix).mp3</location></track>
+ </trackList>
+</playlist></pre>
+
+
+ <a name="toc"/> <h2>Table of Contents</h2>
+ <ol>
+<li><a href="#WhatisXSPF">What is XSPF?</a></li>
+<li><a href="#Example">Example</a></li>
+<li><a href="#Administrativenotes">Administrative notes</a></li>
+<li><a href="#Terminology">Terminology</a></li>
+<li><a href="#Abstractions">Abstractions</a></li>
+<li ><ol>
+<li><a href="#Definingplaylists">Defining playlists</a></li>
+<li><a href="#Whataplaylistisnot">What a playlist is not</a></li>
+<li><a href="#Shareability">Shareability</a></li>
+</ol></li>
+<li><a href="#Elementdefinitions">Element definitions</a></li>
+<li ><ol>
+<li><a href="#xml">xml</a></li>
+<li class="attributes"><ol>
+<li><a href="#version">version</a></li>
+<li><a href="#encoding">encoding</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#playlist">playlist</a></li>
+<li class="attributes"><ol>
+<li><a href="#xmlns">xmlns</a></li>
+<li><a href="#version">version</a></li>
+</ol></li>
+<li class="elements"><ol>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#date">date</a></li>
+<li><a href="#license">license</a></li>
+<li><a href="#attribution">attribution</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#trackList">trackList</a></li>
+<li class="elements"><ol>
+<li><a href="#track">track</a></li>
+<li class="elements"><ol>
+<li><a href="#location">location</a></li>
+<li><a href="#identifier">identifier</a></li>
+<li><a href="#title">title</a></li>
+<li><a href="#annotation">annotation</a></li>
+<li><a href="#creator">creator</a></li>
+<li><a href="#info">info</a></li>
+<li><a href="#image">image</a></li>
+<li><a href="#album">album</a></li>
+<li><a href="#trackNum">trackNum</a></li>
+<li><a href="#duration">duration</a></li>
+<li><a href="#link">link</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+<li><a href="#meta">meta</a></li>
+<li class="attributes"><ol>
+<li><a href="#rel">rel</a></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+</ol></li>
+<li><a href="#Designandarchitecture">Design and architecture</a></li>
+<li ><ol>
+<li><a href="#Contentresolver">Content resolver</a></li>
+<li><a href="#Fuzzynames">Fuzzy names</a></li>
+</ol></li>
+<li><a href="#RequirementsforXSPFplayers">Requirements for XSPF players</a></li>
+<li ><ol>
+<li><a href="#Gracefulfailure">Graceful failure</a></li>
+<li><a href="#Relativepaths">Relative paths</a></li>
+</ol></li>
+<li><a href="#Usecasesforplaylists">Usecases for playlists</a></li>
+<li ><ol>
+<li><a href="#Flagplayerapplication">Flag player application</a></li>
+<li><a href="#Allowstreaming">Allow streaming</a></li>
+<li><a href="#Collectingfragmentedresources">Collecting fragmented resources</a></li>
+<li><a href="#Alternatemediatypes">Alternate media types</a></li>
+<li><a href="#Cachingderivedinfo">Caching derived info</a></li>
+<li><a href="#Metadatastorage">Metadata storage</a></li>
+<li><a href="#Authoringcompilationsforexpressivereasons">Authoring compilations for expressive reasons</a></li>
+</ol></li>
+<li><a href="#Recipes">Recipes</a></li>
+<li ><ol>
+<li><a href="#HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest">How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</a></li>
+<li><a href="#HowtoIconvertXSPFtoM3U">How to I convert XSPF to M3U?</a></li>
+<li><a href="#HowtoIconvertXSPFtoHTML">How to I convert XSPF to HTML?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSMIL">How to I convert XSPF to SMIL?</a></li>
+<li><a href="#HowtoIconvertXSPFtoSoundblox">How to I convert XSPF to Soundblox?</a></li>
+<li><a href="#HowdoIcustomizeXSPFShouldIusenamespaces">How do I customize XSPF? Should I use namespaces?</a></li>
+<li><a href="#HowdoIvalidateXSPF">How do I validate XSPF?</a></li>
+<li><a href="#HowdoIuseMusicBrainzmetadata">How do I use MusicBrainz metadata?</a></li>
+<li><a href="#HowdoIrefertoaBitTorrent">How do I refer to a BitTorrent?</a></li>
+<li><a href="#HowdoIrefertoaMagnetorsha1URI">How do I refer to a Magnet or sha1: URI?</a></li>
+</ol></li>
+<li><a href="#Administrative">Administrative</a></li>
+<li ><ol>
+<li><a href="#Validate">Validate</a></li>
+</ol></li>
+
+ </ol>
+
+
+
+<a name="Administrativenotes"/><h2>Administrative notes</h2>
+
+ <p>Version 0 is frozen and complete. Anybody writing code
+ according to this specification can be very confident that it will
+ not change.</p>
+
+ <p>The home of our working group is <a
+ href="http://xspf.org">http://xspf.org</a>. Members include
+ Dave Brown and Ian Rogers of Yahoo; Dan Brickley from the W3C;
+ Kevin Marks of Technorati; Matthias Friedrich and Robert Kaye of
+ MusicBrainz; Ryan Shaw of UC Berkely; and myself, from Webjay.</p>
+
+ <p>This author of this document is <a
+ href="http://gonze.com">Lucas Gonze</a>. Our group started work
+ in the winter of 2004. The first public draft of this document
+ was May 9, 2004, the most recent was January 6, 2005.</p>
+
+<a name="Terminology"/><h3>Terminology</h3>
+
+ <p>In places in this document I will use the terms MUST, MAY and
+ SHOULD in all caps, which will remind some readers of formal
+ standards. In this document the term should be interpreted to
+ mean that something shouted is important. XSPF is not a
+ standard, it is an ad-hoc project by a group of
+ individuals.</p>
+
+ <p>The terms URI, URL, and URN should be understood as follows: a
+ URL is an address of something that can be fetched by a computer;
+ a URN is a name of something which may be purely an abstraction; a
+ URI is either.</p>
+
+<a name="Abstractions"/><h2>Abstractions</h2>
+
+ <dl>
+
+ <dt><a name="Definingplaylists"/>Defining playlists</dt><!-- first child of abstractions -->
+ <dd>
+ <p>An XSPF playlist describes a sequence of objects to
+ be rendered. Objects might be audio, video, text,
+ playlists, or any other media type. The function of a
+ playlist is to identify the objects and communicate
+ their order.</p>
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Whataplaylistisnot"/>What a playlist is not</dt><!-- first child of abstractions -->
+ <dd>
+ <p>The function of a playlist <em>is not</em> to
+ communicate metadata about the composer, song title,
+ etc. Metadata is hard and there are many providers
+ already. We decided that we couldn't compete, and
+ that there was no need for us to try. Moreover, good
+ metadata does not travel well -- every user has to
+ recreate it. Metadata should come from external
+ sources and namespaces like MusicBrainz or Gracenote;
+ this what the XSPF <span class="elem">link</span>
+ and <span class="elem">meta</span> elements are
+ for.</p>
+
+ <p>The function of a playlist <em>is not</em> to store
+ derived information about objects that a user has a
+ copy of. A playlist is not a catalog. A catalog is
+ computed across hard data like files; it stores
+ information like filesystem paths and the contents of
+ ID3 tags. This data has no value on any machine but
+ the one on which it originated. Sharing this data
+ would be a privacy and security violation. Software
+ which needs access to this data has no reason to
+ maintain it in a standard format, because it has no
+ reason to allow access to it. Standardizing this data
+ would be fruitless, because there are an endless
+ number of measurements that software might take and
+ store. Derived information belongs in
+ a <em>catalog</em>.</p>
+
+ <p>Things a playlist is not, then, are a metadata format or a
+ catalog. We took care to enable these features, but also to
+ avoid duplicating their functionality, poorly.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ <dt><a name="Shareability"/>Shareability</dt><!-- first child of abstractions -->
+ <dd>
+
+ <p>If there is no reason for a playlist to be shared, there is
+ no need for a new format. Even a buggy format does no
+ damage if it is created and consumed by the same software on
+ the same machine. The need for a new format only comes up
+ when a playlist travels from one machine to another, for
+ example when it is published on the internet.</p>
+
+ <p>One type of shareability is between different pieces of
+ software on the same machine. It is common for playlists
+ created with one application to not be usable by another
+ application on the same machine because of different or
+ conflicting interpretations of the playlist format. M3U
+ suffers from this very badly, because M3U playlists often
+ reference files according to a base path which changes from
+ application to application. The XSPF group aimed to fix this
+ by providing unambiguous definitions.</p>
+
+ <p>The other type of shareability is between different
+ machines. For playlists to be meaningful on different
+ machines, they must be able to identify network resources.
+ Audio and video objects are often abstractions like "movie X
+ by director Y" rather than computer-friendly objects like
+ "whatever file can be gotten from the URL http://foo/x/y". To
+ handle this problem, we have provided support for media
+ objects to be found via queries; XSPF identifiers
+ are <em>fuzzy names</em>.</p>
+
+ </dd><!-- first child of abstractions -->
+
+ </dl><!-- end abstractions -->
+
+<a name="Elementdefinitions"/><h2>Element definitions</h2>
+ <dl>
+ <dt><a name="xml"/>xml</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="version"/>version</dt>
+ <dd>1.0</dd>
+ <dt><a name="encoding"/>encoding</dt>
+ <dd>utf-8 recommended to allow unicode characters in text fields</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="playlist"/>playlist</dt>
+ <dd>
+ <dl class="attributes">
+ <dt><a name="xmlns"/>xmlns</dt>
+ <dd>http://xspf.org/ns/0/</dd>
+ <dt><a name="version"/>version</dt>
+ <dd>0</dd>
+ </dl>
+ <dl class="elements">
+ <dt><a name="title"/>title</dt>
+ <dd>A human-readable title for the playlist. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the playlist. This is
+ character data, not HTML, and it may not contain
+ markup. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group, company,
+ etc) that authored the playlist. xspf:playlist elements MAY contain exactly
+ one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URL of a web page to find out more about this playlist. Likely to be
+ homepage of the author, and would be used to find out more about the author
+ and to find more playlists by the author. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="location"/>location</dt>
+ <dd>Source URL for this playlist. xspf:playlist elements
+ MAY contain exactly one.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this playlist. Likely to be a hash or other
+ location-independent name. MUST be a legal URN. xspf:playlist elements MAY
+ contain exactly one.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URL of an image to display in the absence of a
+ //playlist/trackList/image element. xspf:playlist elements MAY contain
+ exactly one.</dd>
+ <dt><a name="date"/>date</dt>
+ <dd>ISO8601 creation date (not last-modified date) of the playlist.
+ xspf:playlist elements MAY contain exactly one.
+
+ <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>
+
+</dd>
+ <dt><a name="license"/>license</dt>
+ <dd>URL of a resource that describes the license under
+ which this playlist was released. xspf:playlist
+ elements may contain zero or one license element.</dd>
+ <dt><a name="attribution"/>attribution</dt>
+ <dd>
+ <p>An ordered list of URIs. The purpose is to satisfy licenses allowing
+ modification but requiring attribution. If you modify such a playlist,
+ move its //playlist/location 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>
+ <p>Such a list can grow without limit, so as a
+ practical matter we suggest deleting ancestors more
+ than ten generations back.</p>
+ <pre>
+<attribution>
+ <location>http://bar.com/modified_version_of_original_playlist.xspf</location>
+ <identifier>somescheme:original_playlist.xspf</identifier>
+ </attribution></pre>
+ </dd>
+
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web resources to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more link elements.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource type.</dd>
+ </dl>
+ <p>URL of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata to be included in XSPF
+ documents without breaking XSPF validation. xspf:playlist elements MAY
+ contain zero or more meta elements.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URI of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. This is plain old
+ text, not XML, and it may not contain markup.
+ xspf:playlist elements MAY contain exactly one.</p>
+ </dd>
+ <dt><a name="trackList"/>trackList</dt>
+ <dd>
+ <p>Ordered list of xspf:track elements to be rendered.
+ The sequence is a hint, not a requirement; renderers
+ are advised to play tracks from top to bottom unless
+ there is an indication otherwise.<p/>
+
+ <p>If an xspf:track element cannot be rendered, a
+ user-agent MUST skip to the next xspf:track element
+ and MUST NOT interrupt the sequence.</p>
+
+ <p>xspf:playlist elements MUST contain one and only
+ one trackList element.</p>
+ <dl class="elements">
+ <dt><a name="track"/>track</dt>
+ <dd>
+ <dl class="elements">
+ <dt><a name="location"/>location</dt>
+ <dd>URL of resource to be rendered. Probably an audio resource, but
+ MAY be any type of resource with a well-known duration, such as
+ video, a SMIL document, or an XSPF document. The duration of the
+ resource defined in this element defines the duration of rendering.
+ xspf:track elements MAY contain zero or more
+ location elements, but a user-agent MUST NOT render more than one
+ of the named resources.</dd>
+ <dt><a name="identifier"/>identifier</dt>
+ <dd>Canonical ID for this resource. Likely to be
+ a hash or other location-independent name,
+ such as a MusicBrainz identifier or isbn URN
+ (if there existed isbn numbers for audio).
+ MUST be a legal URN. xspf:playlist elements
+ MAY contain zero or more identifier
+ elements.</dd>
+ <dt><a name="title"/>title</dt>
+ <dd>Human-readable name of the track that authored the resource
+ which defines the duration of track rendering. This value is
+ primarily for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="annotation"/>annotation</dt>
+ <dd>A human-readable comment on the track. This
+ is character data, not HTML, and it may not
+ contain markup. xspf:track elements MAY
+ contain exactly one.</dd>
+ <dt><a name="creator"/>creator</dt>
+ <dd>Human-readable name of the entity (author, authors, group,
+ company, etc) that authored the resource which defines the duration
+ of track rendering. This value is primarily for fuzzy lookups,
+ though a user-agent may display it. xspf:track
+ elements MAY contain exactly one.</dd>
+ <dt><a name="info"/>info</dt>
+ <dd>URL of a place where this resource can be bought or more info
+ can be found.</dd>
+ <dt><a name="image"/>image</dt>
+ <dd>URL of an image to display for the duration of the track.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="album"/>album</dt>
+ <dd>Human-readable name of the collection from which the resource
+ which defines the duration of track rendering comes. For a song
+ originally published as a part of a CD or LP, this would be the
+ title of the original release. This value is primarily for fuzzy
+ lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one.</dd>
+ <dt><a name="trackNum"/>trackNum</dt>
+ <dd>Integer with value greater than zero giving the ordinal
+ position of the media on the xspf:album. This value is primarily
+ for fuzzy lookups, though a user-agent may display it.
+ xspf:track elements MAY contain exactly
+ one. It MUST be a valid <a href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML Schema nonNegativeInteger</a>.</dd>
+
+ <dt><a name="duration"/>duration</dt>
+
+ <dd>The time to render a resource, in
+ milliseconds. It MUST be a valid <a
+ href="http://www.w3.org/TR/xmlschema-2/#dt-nonNegativeInteger">XML
+ Schema nonNegativeInteger</a>. This value is
+ only a hint -- different XSPF generators will
+ generate slightly different values. A
+ user-agent MUST NOT use this value to
+ determine the rendering duration, since the
+ data will likely be low quality. xspf:track
+ elements MAY contain exactly one duration
+ element.</dd>
+ <dt><a name="link"/>link</dt>
+ <dd>
+ <p>The link element allows non-XSPF web
+ resources to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><link rel="http://foaf.org/namespace/version1">http://socialnetwork.org/foaf/mary.rdfs</link></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URN of a resource type.</dd>
+ </dl>
+ <p>URL of a resource.</p>
+ </dd>
+ <dt><a name="meta"/>meta</dt>
+ <dd>
+ <p>The meta element allows non-XSPF metadata
+ to be included in
+ xspf:track elements
+ without breaking XSPF validation.</p>
+ <pre><meta rel="http://example.org/key">value</meta></pre>
+ <dl class="attributes">
+ <dt><a name="rel"/>rel</dt>
+ <dd>URN of a resource defining the metadata.</dd>
+ </dl>
+ <p>Value of the metadata element. This is
+ character data, not HTML, and it may not
+ contain markup. xspf:playlist elements MAY
+ contain exactly one.</p>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+ </dd>
+ </dl>
+
+<a name="Designandarchitecture"/><h2>Design and architecture</h2>
+
+ <dl>
+
+ <dt><a name="Contentresolver"/>Content resolver</dt>
+
+ <dd>
+
+ <p>On a surface level you can use XSPF like any other playlist
+ format. Drop a bunch of filenames into an XSPF document, prepend
+ "file://" to each, and you're ready to go. Under the surface
+ there is much more.</p>
+
+ <p>The guiding design principle was to separate the functionality
+ of a catalog of files from the functionality of a list of songs.
+ Most MP3 players have some sort of cache for file information.
+ This cache stores a list, or catalog, of available files and
+ metadata from ID3 tags and other sources. XSPF is not a catalog
+ format. XSPF exists only to say which songs to play. Almost
+ everything in XSPF is for the purpose of answering the
+ question <em>which resource</em>, rather than the
+ question <em>what is this resource</em>.</p>
+
+ <p>If XSPF is not a catalog format, what is it? XSPF is an
+ intermediate format. We expected a new kind of software called
+ a <em>content resolver</em> to do the job of converting XSPF to a
+ plain old list of files or URLs. A content resolver would be
+ smart enough to keep your playlists from breaking when you move
+ your MP3s from /mp3s to /music/mp3. It would be able to figure
+ out that a playlist entry by the artist "Hank Williams" with the
+ title "Your Cheating Heart" could be satisfied by the file
+ /mp3s/hankwilliams/yourcheatingheart.mp3. It might even know how
+ to query the iTunes music store or another online provider to
+ locate and download a missing song.</p>
+
+ <p>The content resolver maintains the catalog of your songs in
+ whatever format it prefers. It might use a flatfile, a file in
+ the Berkeley DB format, or a SQL database. It might use only ID3
+ metadata, but it might also know how to query MusicBrainz or
+ another metadata service.</p>
+ </dd>
+
+ <dt><a name="Fuzzynames"/>Fuzzy names</dt>
+ <dd>Any given track can be identified in a number of ways. We
+ provided means for absolute identifiers like URLs, filesystem
+ paths and secure hashes, but also for query-based identifiers --
+ free text fields like artist and work title and numeric fields
+ for song length, all of which together should be enough for a
+ good content resolver to turn into files.
+ </dd>
+
+ </dl>
+
+<a name="RequirementsforXSPFplayers"/><h2>Requirements for XSPF players</h2>
+ <dl><!-- begin requirements -->
+ <dt><a name="Gracefulfailure"/>Graceful failure</dt><!-- first child of normative -->
+ <dd>
+ <p>If a media player is unable to render a resource, the show
+ MUST go on. Playlists exist in time; a player that stops
+ processing when it encounters an error is considered broken;
+ it is not conformant with the standard; it must be shunned by
+ the community and made an outcast. Players will frequently
+ encounter resources that they cannot render -- this is not a
+ fatal error unless the player stops processing the
+ playlist.</p>
+ <p></p>
+ </dd>
+
+ <dt><a name="Relativepaths"/>Relative paths</dt><!-- first child of normative -->
+ <dd>
+ <p>Relative paths MUST be resolved according to the <a
+ href="http://www.w3.org/TR/xmlbase/">XML Base</a>
+ specification or <a
+ href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC
+ 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+
+ </dd>
+
+ </dl><!-- end requirements -->
+
+<a name="Usecasesforplaylists"/><h2>Usecases for playlists</h2>
+
+ <dl>
+
+ <dt><a name="Flagplayerapplication"/>Flag player application</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on a link to an audio or
+ video object in their browser. The browser needs to
+ hand the object off to a helper application like an
+ MP3 player. If there is an intermediate playlist
+ object between the browser and helper application, and
+ the browser needs to ensure that the right helper is
+ launched, the playlist needs to be of a type which is
+ mapped to the same helper application.</p>
+
+ <p>Typical solution: Use a dedicated playlist format
+ for almost every media subtype. For Real audio there
+ is RAM; for MP4 video there is M4U; for MP3 there is
+ M3U; even though RAM, M4U and M3U are almost identical
+ in syntax. The QuickTime format is able to avoid this
+ problem only because the container format and media
+ format are integrated -- a QuickTime file is both a
+ playlist and a media object.</p>
+
+ <p>XSPF' solution: The XSPF format does not yet have a
+ solution to this problem, because the working group
+ has not yet tackled it. (Though I can speculate that
+ a content resolver in between the browser and helper
+ application would have the means to do it).</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Allowstreaming"/>Allow streaming</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: A user clicks on an audio or video link.
+ Before handing off control to the helper application,
+ the browser must download whatever the link points to.
+ For streaming media this makes no sense; either the
+ download will never finish or waiting for a complete
+ download defeats the purpose.</p>
+
+ <p>Typical solution: rather than linking to an audio
+ or video document, link to a playlist containing a URL
+ of an audio or video document. Playlists used for
+ this purpose often contain only a single URL. The Pls
+ format, which is used for MP3-based webcasting, and
+ which contains a single URL of a never-ending stream,
+ takes this approach.</p>
+
+ <p>XSPF' solution: any reasonably compact playlist
+ format supports this equally well. This rules out
+ iTunes library format and sometimes QuickTime, but
+ allows XSPF along with M3U, Pls and other relatively
+ terse formats.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Collectingfragmentedresources"/>Collecting fragmented resources</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a very large object like a DVD
+ rip. The likelyhood of downloading the entire object
+ in one shot is low, so the object has been split into
+ pieces. The object then needs to be reassembled on
+ the client side.</p>
+
+ <p>Typical solution: Create a zip file or tarball,
+ which use checksums to ensure integrity of the
+ download; start by sending a playlist which acts a
+ file manifest and allows a user agent to download
+ sub-objects in digestible chunks. However, a manifest
+ has to express paths to related objects according to a
+ filesystem which does not exist on the client, there
+ has to be agreement between the client and server on
+ how to interpret relative paths in a playlist. The
+ problem is that few playlist formats -- only SMIL, to
+ my knowledge -- define the meaning of relative paths
+ in a playlist.</p>
+
+ <p>XSPF' solution: XSPF clearly defines the meaning of
+ relative paths according to the rule that a client
+ must interpret relative paths in a playlist according
+ to the XML Base specification or IETF RFC 2396.</p>
+
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Alternatemediatypes"/>Alternate media types</dt><!-- first child of usecases -->
+ <dd>
+
+ <p>Scenario: There is a renderer which is capable of
+ rendering one form of a media object but not another.
+ The server is able to deliver the object in either
+ format, but it needs to communicate URLs for both.
+ Though HTTP content negotiation can be used for
+ instances where the renderer contacts the server
+ directly, it doesn't support protocol negotiation, and
+ it can't be used in non-HTTP protocols.</p>
+
+ <p>Typical solution: This is particularly a problem
+ for Real, which has a large installed base of obsolete
+ software to be babied. The solution is to delver
+ alternate URLs within the same playlist and allow the
+ client to choose. The RAM format allows both a pnm:
+ and a rtsp: URL within the same playlist, separated by
+ a line containg the keyword "--stop--".</p>
+
+ <p>XSPF' solution: An XSPF track object can contain
+ multiple identifiers or locations for the same media
+ object.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Cachingderivedinfo"/>Caching derived info</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: An MP3 player needs to access information
+ about media objects which is too expensive to compute
+ in real time. For a large number of file a user can't
+ wait to re-read ID3 tags, computing SHA1 hashes, or
+ perform a fourier transform for each.</p>
+ <p>Typical solution: An MP3 player computes the
+ information once, the first time it encounters an
+ object, then caches the data. The iTunes library
+ format stores computed information like ID3 data in
+ the global catalog and playlist.</p>
+ <p>XSPF' solution: XSPF defers this information to an
+ external module called the content resolver, and
+ mandates that the information not be included in
+ shared playlists.</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Metadatastorage"/>Metadata storage</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A user needs information about high level
+ concepts like artist and song title rather than
+ machine-level concepts like file name and bit rate.
+ How should artist and song title be communicated, and
+ how should they be stored?</p>
+ <p>Typical solution: Derive the metadata according to
+ an application-defined process like extracting ID3
+ tags, then then store a copy of the metadata in any
+ playlists that reference a media object. The EXTINF
+ property of the extended M3U format is used in this
+ way.</p>
+ <p>XSPF' solution: XSPF defers this functionality to
+ other sources. Metadata is hard; there are already
+ many projects to deal with it, some of which are very
+ good. Metadata is attached to an XSPF track according
+ to whatever syntax an imported vocabulary defines.
+ XML namespaces may be used, but the preferred syntax
+ is the XSPF <span class="elem">link</span> and <span
+ class="elem">meta</span> elements. (These elements
+ allows us to validate metadata from external sources,
+ while namespaces don't.)</p>
+ </dd><!-- first child of usecases -->
+
+ <dt><a name="Authoringcompilationsforexpressivereasons"/>Authoring compilations for expressive reasons</dt><!-- first child of usecases -->
+ <dd>
+ <p>Scenario: A businessperson wants to make a batch of
+ videos of related talks from a conference because
+ watching them in a shared context gives a deeper
+ understanding of the subject as a whole.</p>
+
+ <p>Typical solution: A user compiles copies of the
+ videos and puts them in the same location, maybe in
+ the same directory on a web server, maybe in the same
+ directory on a hard drive. The user then puts the
+ locations, whether paths or URLs, into a file in the
+ M3U format.</p>
+
+ <p>XSPF' solution: The XSPF <span
+ class="elem">trackList</span> element contains a
+ sequence of <span class="elem">track</span> elements,
+ each of which points to one of the objects.</p>
+ </dd><!-- first child of usecases -->
+
+ </dl><!-- end usecases -->
+
+<a name="Recipes"/><h2>Recipes</h2>
+
+ <dl>
+
+ <dt><a name="HowdoIsetrelativepathsinanXSPFplaylistforexampleifIwanttouseitasafilemanifest"/>How do I set relative paths in an XSPF playlist, for example if I want to use it as a file manifest?</dt>
+ <dd><p>See the <a href="http://www.w3.org/TR/xmlbase/">XML Base</a> specification or <a href="http://www.w3.org/TR/xmlbase/#RFC2396">IETF RFC 2396</a>:</p>
+
+ <blockquote>The rules for determining the base URI can be
+ summarized as follows (highest priority to lowest):
+ <ol>
+ <li>The base URI is embedded in the document's content.</li>
+ <li>The base URI is that of the encapsulating entity (message,
+ document, or none).</li>
+ <li>The base URI is the URI used to retrieve the entity.</li>
+ <li>The base URI is defined by the context of the application.</li>
+ </ol>
+ </blockquote>
+ </dd>
+
+ <dt><a name="HowtoIconvertXSPFtoM3U"/>How to I convert XSPF to M3U?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2m3u.xsl">xspf2m3u.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoHTML"/>How to I convert XSPF to HTML?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2html.xsl">xspf2html.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSMIL"/>How to I convert XSPF to SMIL?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2smil.xsl">xspf2smil.xsl</a> stylesheet.</dd>
+
+ <dt><a name="HowtoIconvertXSPFtoSoundblox"/>How to I convert XSPF to Soundblox?</dt>
+ <dd>Use the <a href="http://gonze.com/xspf/xspf2soundblox.xsl">xspf2soundblox.xsl</a> stylesheet.</dd>
+ <dt><a name="HowdoIcustomizeXSPFShouldIusenamespaces"/>How do I customize XSPF? Should I use namespaces?</dt>
+ <dd>Use the meta or link elements. Use meta if the element
+ contains a single value, like "blue" or "rock"; use link if the
+ element contents are a URL. Try to avoid using namespaces to
+ add fields, because namespaced items cannot be validated by an
+ XSPF validator.</dd>
+
+ <dt><a name="HowdoIvalidateXSPF"/>How do I validate XSPF?</dt>
+ <dd><p>Robert Kaye has created a Relax NG schema for XSPF draft 8 at <a href="http://mayhem-chaos.net/stuff/xspf-draft8.rng">http://mayhem-chaos.net/stuff/xspf-draft8.rng</a>. You can use <a href="http://www.thaiopensource.com/relaxng/jing.html">Jing</a> to invoke it.</p>
+ <p>For users of Emacs nxml-mode, Ryan Shaw has posted a .rnc
+ version of Robert's schema at <a
+ href="http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html">http://lists.musicbrainz.org/pipermail/playlist/2004-October/000429.html</a>.
+ This is just a matter of putting the .rnc file in the schema/
+ subdirectory of your nxml-mode installation. nxml-mode will
+ find it automatically and add it to the list of available
+ schemas; if you begin authoring an XSPF playlist, nxml-mode
+ will choose the correct schema by examining the root element
+ name.</p>
+ </dd>
+
+ <dt><a name="HowdoIuseMusicBrainzmetadata"/>How do I use MusicBrainz metadata?</dt>
+ <dd>
+ Rather than include the literal artist name, song duration, etc, for a track within a playlist, MusicBrainz gives the URL of an XML file containing these items. Assume that the MusicBrainz definition of what a track listing means is at http://musicbrainz.org/track. (There is nothing at that URL, which is fine -- the URL in an XSPF meta[@rel] attribute works the same way as the URL in an XML namespace declaration). A typical track listing has a URL like http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429.
+ <div class="example">
+<track>
+ <identifier>bdc846e7-6c26-4193-82a6-8d1b5a4d3429</identifier>
+ <title>Smoke Two Joints</title>
+ <creator>Sublime</creator>
+ <duration>175466</duration>
+ <meta rel="http://musicbrainz.org/track">http://musicbrainz.org/mm-2.1/track/bdc846e7-6c26-4193-82a6-8d1b5a4d3429</meta>
+</track>
+ </div>
+
+ </dd>
+
+ <dt><a name="HowdoIrefertoaBitTorrent"/>How do I refer to a BitTorrent?</dt>
+ <dd>Put the torrent file in a playlist/trackList/track/location element.</dd>
+
+ <dt><a name="HowdoIrefertoaMagnetorsha1URI"/>How do I refer to a Magnet or sha1: URI?</dt>
+ <dd>A sha1: URI is a location independent canonical ID, so it
+ belongs in a playlist/trackList/track/identifier element. A
+ Magnet URI is resolvable, so belongs in
+ playlist/trackList/track/location.</dd>
+
+ </dl>
+
+<a name="Administrative"/><h2>Administrative</h2>
+
+ <dl>
+ <dt><a name="Validate"/>Validate</dt>
+ <dd>
+ <ol>
+ <li><a href="http://validator.w3.org/check?uri=http%3A%2F%2Fgonze.com%2Fxspf%2Fxspf-draft-8.html">HTML</a></li>
+ <li><a href="http://jigsaw.w3.org/css-validator/validator?uri=http://gonze.com/xspf/xspf-draft-8.html">CSS</a></li>
+ </ol>
+ </dd>
+ </dl>
+
+ </body>
+</html>
More information about the commits
mailing list