<html><head></head><body style="font-family: Monospace;"><div>ahoy all,</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>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:</div><div><br></div><div><?xml version="1.0" encoding="UTF-8"?></div><div><playlist version="1" xmlns="http://xspf.org/ns/0/"></div><div> <trackList></div><div> <track></div><div> <location>http://example.com/song_1.ogg</location></div><div> <location>http://mirror.xyz/example.com/song_1.ogg</location></div><div> </track></div><div> <track</div><div> <location>http://example.com/song_2.ogg</location></div><div> <location>http://example.com/song_2.mp3</location></div><div> </track></div><div> </trackList></div><div></playlist></div><div><br></div><div>my question is whether this is for allowing:</div><div><br></div><div>- multiple locations of the same type of resource (e.g. MP3 file at original source and mirror) as in song_1 above?</div><div><br></div><div>- 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?</div><div><br></div><div>- or maybe both? and/or others?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>thus: is there an standard or recommended behavior for handling/resolving multiple `<location>` elements for a single `<track>` in XSPF?</div><div><br></div><div>thanks</div><div><br></div><div> [1]: <a href="http://xspf.org">http://xspf.org</a></div><div> [2]: <a href="http://xspf.org/xspf-v1.html">http://xspf.org/xspf-v1.html</a></div><div> [3]: <a href="http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.1">http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.1</a></div><div><br></div><div><br></div><div>PS: also posted to StackExchange</div><div><br></div><div><a href="https://stackoverflow.com/questions/41101769/multiple-location-elements-per-track-in-xspf">https://stackoverflow.com/questions/41101769/multiple-location-elements-per-track-in-xspf</a></div><div><br></div><div><br></div><div class="-x-evo-signature-wrapper"><span><pre>--
http://waynedpj.in-giro.xyz</pre></span></div></body></html>