View source for XSPF v1 Notes and Errata

This page lists errata of the XSPF version 1 document and also gives advice on using and understanding XSPF.

= Notes =

== <trackList> and <trackNum> spelling ==
Please note that ''trackList'' and ''trackNum'' elements MUST NOT be written
in all lowercase since XSPF is case-sensitive. These two
are the only elements containing capital letters so just remember ''trackList''
and ''trackNum'' and your XSPF will be fine.

== Absolute vs. relative URIs in key attributes ==
The attributes ''rel'' (<meta> and <link>) and ''application'' (<extension>)
are by XSPF v1 specification allowed to hold relative URIs. For example this
meta element is legal in XSPF v1:

 <meta rel="playCount">14</meta>

While this might look elegant it comes with several drawbacks:
* You might easily forget that this string is a URI and include non-URI characters like spaces by mistake (e.g. rel="play count" is not valid)
* You lose the namespace concept: nobody will know what or whom this ''key'' belongs to or came from

For these reasons it is strongly recommended to use absolute URIs as keys instead:

 <meta rel="http://example.com/track/meta/playCount/1/0/">14</meta>

== Version information in key attributes  ==
When defining you own extensions to XSPF you will have to choose
an application URI for your onw extensions:

 <extension application="http://example.com/myext/">
   ..
 </extension>

Please consider including version information in your application
URIs and increase it whenever the structure of your extension changes:

 <extension application="http://example.com/xspf/track/1/0/">
   ..
 </extension>

This enables others to properly distinct different versions of your extensions
without the need to do ''version guessing''.
Adding version information to ''rel'' of <meta> and <link> is a good idea as well:

 <meta rel="http://example.com/track/meta/playCount/1/0/">14</meta>

== Element order ==
In XSPF child elements can appear in any order. That means that
for example both these tracks are valid for XSPF v1.

As appearing in the specification:
 <track>
   <creator>Creator first</creator>
   <album>Album after</album>
 </track>

Also valid:
 <track>
   <album>Album first</album>
   <creator>Creator after</creator>
 </track>

This is not mentioned in the specification and might
have been ignored by some implementations. Thus for people
implementing XSPF support that means:
* XSPF readers must be able to deal with arbitrary element order
* XSPF writers should always produce XSPF files with elements in the order appearing in the specification for maximum compatibility.

To save you extracting this information yourself the order
of elements appearing in the XSPF specification is:
* ''playlist''
* ''playlist.title''
* ''playlist.creator''
* ''playlist.annotation''
* ''playlist.info''
* ''playlist.location''
* ''playlist.identifier''
* ''playlist.image''
* ''playlist.date''
* ''playlist.license''
* ''playlist.attribution''
* ''playlist.attribution.location''
* ''playlist.attribution.identifier''
* ''playlist.link''
* ''playlist.meta''
* ''playlist.extension''
* ''playlist.trackList''
* ''playlist.trackList.track''
* ''playlist.trackList.track.location''
* ''playlist.trackList.track.identifier''
* ''playlist.trackList.track.title''
* ''playlist.trackList.track.creator''
* ''playlist.trackList.track.annotation''
* ''playlist.trackList.track.info''
* ''playlist.trackList.track.image''
* ''playlist.trackList.track.album''
* ''playlist.trackList.track.trackNum''
* ''playlist.trackList.track.duration''
* ''playlist.trackList.track.link''
* ''playlist.trackList.track.meta''
* ''playlist.trackList.track.extension''

== Whitespace==
Whitespace handling in XML can be a little difficult to understand at first.
Since XSPF is based on XML, people implementing XSPF readers or writers
do have to know about the basics of whitespace handling in XML.
The good things is we summed it up here to make things easier for you.

=== Ignore in non-leaf elements ===
Whitespace in elements only holding child elements (but no text)
must be ignored.

Elements affected:
* ''playlist''
* ''playlist.attribution''
* ''playlist.trackList''
* ''playlist.trackList.track''

=== Process in non-string leaf elements ===
In XSPF all elements with non-string content (i.e. of type [http://www.w3.org/TR/xmlschema-2/#dateTime dateTime], [http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger nonNegativeInteger], or [http://www.w3.org/TR/xmlschema-2/#anyURI anyURI])
must be process with the [http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace "collapse" method]. Sounds difficult but is easy:
* Leading and trailing whitespace ('\t'(0x08), '\n'(0x0a), '\r'(0x0d), ' '(0x20)) is removed
* Whitespace "in the middle" is converted to a single space (think s/[\t\n\r ]+/ / Perl people)

For example the three-line text
   ABC
 DEF	GHI
 

will become

 ABC GHI DEF

Elements affected:
* ''playlist.attribution.identifier''
* ''playlist.attribution.location''
* ''playlist.date''
* ''playlist.identifier''
* ''playlist.image''
* ''playlist.info''
* ''playlist.license''
* ''playlist.link''
* ''playlist.location''
* ''playlist.meta''
* ''playlist.trackList.track.duration''
* ''playlist.trackList.track.identifier''
* ''playlist.trackList.track.image''
* ''playlist.trackList.track.info''
* ''playlist.trackList.track.link''
* ''playlist.trackList.track.location''
* ''playlist.trackList.track.meta''
* ''playlist.trackList.track.trackNum''

=== Keep in "real" string leaf elements ===
Whitespace in string elements is significant and has to be preserved.
So if ''<annotation>'' contains line feeds the annotation text
really spans several lines:
 <annotation>Line feeds and even spaces are preserved.
 This example annotation spans two lines</annotation>

Elements affected:
* ''playlist.annotation''
* ''playlist.creator''
* ''playlist.title''
* ''playlist.trackList.track.album''
* ''playlist.trackList.track.annotation''
* ''playlist.trackList.track.creator''
* ''playlist.trackList.track.title''

=== Do X in Extensions ===
Whitespace handling inside of extension
elements depends on the specific extension.

Elements affected:
* ''playlist.extension''
* ''playlist.trackList.track.extension''

== URI RFC used ==
The XSPF v1 specification mentions RFC 2396 when talking about URIs. As [http://lists.w3.org/Archives/Public/uri/2007Jul/0001.html asking on uri@w3.org] revealed, we should have referred to ''STD 66'' instead which stands for ''"latest RFC of URI"'' (RFC 3986 as of 2007-07-09). What does that mean practically?

This means:
* You can use IPv6 host part URIs in XSPF v1
* You should use a RFC 3986 parser for your XSPF v1 implementation

== <playlist.location> and privacy ==
Saving an absolute file location in ''playlist.location'' as is not a good idea as it has potential to hurt privacy. To give an example this playlist location
 
 <location>file:///home/bob/porn/soundtrack/ginawild34.xspf</location>

might reveal information that Bob would have liked to keep private.
This problem is not very XSPF-specific actually, for instance [https://bugs.launchpad.net/inkscape/+bug/168958 Inkscape does this wrong with SVG].

== <playlist.location> vs. xml:base ==

=== playlist.location ===
.. contains the (possibly relative) URI recommended to retrieve the surrounding playlist (or an updated version of it). playlist.location is ''not'' an embedded base URI used to resolve relative URIs, ''[[#xml:base|xml:base]]'' is. ''playlist.location'' can be thought of as XSPF's counterpart to [http://tools.ietf.org/html/rfc4287 Atom]'s [http://tools.ietf.org/html/rfc4287#section-4.1.1 ''feed.link''] element:

 atom:feed elements SHOULD contain one atom:link element with a rel
 attribute value of "self".  This is the preferred URI for
 retrieving Atom Feed Documents representing this Atom feed.

=== xml:base ===
.. is an xml-wide attribute defined in [http://www.w3.org/TR/xmlbase/ XML Base].
The ''xml:base'' attribute can appear in any element. The Base URI for an element
is computed from ''the stack of xml:base attributes''.
The URI in ''xml:base'' can be relative so you will need an ''external Base URI''
as a ''backup'' (from [http://www.w3.org/TR/xmlbase/#rfc2396 XML Base, 4.1]):

# <s>The base URI is embedded in the document's content.</s>
# The base URI is that of the encapsulating entity (message, document, or none).
# The base URI is the URI used to retrieve the entity.
# The base URI is defined by the context of the application.

Here is an example of ''xml:base'' in XSPF:

 <?xml version="1.0" encoding="UTF-8"?>
 <playlist version="1" xmlns="http://xspf.org/ns/0/" xml:base="one/">
   <trackList xml:base="two/">
     <track xml:base="../../three/">
       <location>four</location>
     </track>
   </trackList>
 </playlist>

If our ''external Base URI'' would be http://example.org/ the location above would
resolve to http://example.org/three/four.

Though XML Base is mentioned in the XSPF specification, the ''xml:base'' attribute is not mentioned explicitly. Both XSPF-0 and XSPF-1 support the ''xml:base'' attribute and your implementation of XSPF should do as well.

== Role of track creator ==

The //playlist/trackList/track/creator element is defined as "name of the entity (author, authors, group, company, etc) that authored the resource."  However this leaves ambiguity as to the difference between performer and author.  Please note that this element might contain any one of the performer, newsreader, composer, author, etc.

= Errata =

== 4.1.1.2.12.2 content ==
This paragraph describes the content of [http://www.xspf.org/xspf-v1.html#rfc.section.4.1.1.2.12.2 ''playlist.meta''].
It also reads "xspf:playlist elements MAY contain exactly one" which
does not make sense for the content of an element and can be safely ignored.

== 4.1.1.2.14.1.1.1.12.2 content ==
This paragraph describes the content of [http://www.xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.12.2 ''playlist.trackList.track.meta''].
It also reads "xspf:playlist elements MAY contain exactly one" which
does not make sense for the content of an element and can be safely ignored.

[[Category:XSPF]]