[Playlist] resolving multiple <location> elements per <track> in XSPF?

Wayne DePrince Jr. waynedpj at in-giro.xyz
Mon Dec 12 20:45:06 UTC 2016

ahoy all,

	for parsing an [XSPF][1] document, the [specification][2] states that
[a `<track>` element can have zero or more `<location>` elements to define the
URI of a resource to be rendered][3].  for example:

<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">

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?  and/or others?

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 times when 2 playlists would be 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?


  [1]: http://xspf.org
  [2]: http://xspf.org/xspf-v1.html
  [3]: http://xspf.org/xspf-v1.html#rfc.section.

PS: also posted to StackExchange


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20161212/228ff49c/attachment.html>

More information about the Playlist mailing list