for parsing an XSPF document, the specification states that a <track>
element can have zero or more <location>
elements to define the URI of a resource to be rendered. for example:
<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
<trackList>
<track>
<location>http://example.com/song_1.ogg</location>
<location>http://mirror.xyz/example.com/song_1.ogg</location>
</track>
<track>
<location>http://example.com/song_2.ogg</location>
<location>http://example.com/song_2.mp3</location>
</track>
</trackList>
</playlist>
my question is whether this is for allowing:
multiple locations of the same type of resource (e.g. MP3 file at original source and mirror) as in song_1 above?
or for different types of the resource (e.g. use multiple locations to provide both an Ogg Vorbis and MP3 version of a track) as in song_2 above?
or maybe both?
currently VLC and Audacious both use the last <location>
provided in a <track>
, even if it is not available. thus they seem to simply be using only the last <location>
element, which does not seem to be what the specification intends. either way they do not perform either of the resolve cases i list above.
obviously how these locations are interpreted changes the expected behavior of a resolver of <track>
elements that include <location>
elements. the first case provides a nice fallback solution. more interestingly for me, the second case simplifies the case where 2 playlists are needed, 1 for Ogg Vorbis and 1 for MP3 versions of the tracks, as would have to be done with M3U and PLS for example.
thus: is there an standard or recommended behavior for handling/resolving multiple <location>
elements for a single <track>
in XSPF?
thanks