<html><head></head><body style="font-family: Monospace;"><div>ahoy Lucas,</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>thanks for the helpful reply and for also updating the SO question.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>so i can assume that a resolver could allow the user to choose the preferred location priorities (e.g. first search local library, then remote Ogg Vorbis locations, then remote MP3 locations): basically the spec is intentionally ambiguous as to how the multiple locations are used?</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>i believe having multiple locations is a great advantage of the XSPF format, even if it is not being utilized as of yet. once i have my playlist finished and available i would be happy to submit a bug report to VLC and Audacious regarding their location support (they also seem to have a problem with nested xml:base <a href="https://wiki.xiph.org/XSPF_v1_Notes_and_Errata#.3Cplaylist.location.3E_vs._xml:base">https://wiki.xiph.org/XSPF_v1_Notes_and_Errata#.3Cplaylist.location.3E_vs._xml:base</a> but i have to investigate that further). is there a test suite or something that i could point the developers to for XSPF compliance besides the validators?</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>again, thanks for the help as well as the format ;)</div><div><br></div><div>peace, w</div><div><br></div><div><br></div><div>Il giorno lun, 12/12/2016 alle 13.36 -0800, Lucas Gonze ha scritto:</div><blockquote type="cite"><div>Wayne,</div><div><br></div><div>The cardinality of the location element is "zero or more." This was chosen</div><div>instead of "zero or one" with the intention of supporting both of the use</div><div>cases you mention (fallbacks and alternate media types).</div><div><br></div><div>What VLC and Audacious do in only using the last location is an incorrect</div><div>implementation.</div><div><br></div><div>That said, our strategy was to make it easy to build a weak resolver, and</div><div>possible to build a strong one. If VLC or Audacious become stronger over</div><div>time by adding support for redundant locations, that is the process playing</div><div>out as hoped.</div><div><br></div><div>I wonder what we can do to help this happen in the VLC and Audacious</div><div>communities.</div><div><br></div><div>-Lucas</div><div><br></div><div><br></div><div>On Mon, Dec 12, 2016 at 12:45 PM, Wayne DePrince Jr. <<a href="mailto:waynedpj@in-giro.xyz">waynedpj@in-giro.xyz</a>></div><div>wrote:</div><div><br></div><blockquote type="cite"><div>ahoy all,</div><div><br></div><div>for parsing an [XSPF][1] document, the [specification][2] states that [a</div><div>`<track>` element can have zero or more `<location>` elements to define the</div><div>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="<a href="http://xspf.org/ns/0/" >"="">http://xspf.org/ns/0/"></a>;</div><div> <trackList></div><div> <track></div><div> <location><a href="http://example.com/song_1.ogg</location>">http://example.com/song_1.ogg</location></a>;</div><div> <location><a href="http://mirror.xyz/example.com/song_1.ogg</location>">http://mirror.xyz/example.com/song_1.ogg</location></a>;</div><div> </track></div><div> <track</div><div> <location><a href="http://example.com/song_2.ogg</location>">http://example.com/song_2.ogg</location></a>;</div><div> <location><a href="http://example.com/song_2.mp3</location>">http://example.com/song_2.mp3</location></a>;</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</div><div>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</div><div>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</div><div>`<track>`, even if it is not available. thus they seem to simply be using</div><div>only the last `<location>` element, which does not seem to be what the</div><div>specification intends. either way they do not perform either of the</div><div>resolve cases i list above.</div><div><br></div><div>obviously how these locations are interpreted changes the expected</div><div>behavior of a resolver of `<track>` elements that include `<location>`</div><div>elements. the first case provides a nice fallback solution. more</div><div>interestingly for me, the second case simplifies the times when 2</div><div>playlists would be needed: 1 for Ogg Vorbis and 1 for MP3 versions of the</div><div>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</div><div>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">https://stackoverflow.com/questions/41101769/multiple</a>-</div><div>location-elements-per-track-in-xspf</div></blockquote></blockquote><div><br></div><div class="-x-evo-signature-wrapper"><span><pre>--
http://waynedpj.in-giro.xyz</pre></span></div></body></html>