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

[Wayne DePrince Jr.]

ahoy Lucas,
	thanks for the helpful reply and for also updating the SO question.
	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?
	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 https://wiki.xiph.org/XSPF_v1_Notes_and_Errata#.3Cplaylis
t.location.3E_vs._xml:base 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?
	again, thanks for the help as well as the format ;)
peace, w
Il giorno lun, 12/12/2016 alle 13.36 -0800, Lucas Gonze ha scritto:
> Wayne,
> 
> The cardinality of the location element is "zero or more." This was chosen
> instead of "zero or one" with the intention of supporting both of the use
> cases you mention (fallbacks and alternate media types).
> 
> What VLC and Audacious do in only using the last location is an incorrect
> implementation.
> 
> That said, our strategy was to make it easy to build a weak resolver, and
> possible to build a strong one. If VLC or Audacious become stronger over
> time by adding support for redundant locations, that is the process playing
> out as hoped.
> 
> I wonder what we can do to help this happen in the VLC and Audacious
> communities.
> 
> -Lucas
> 
> 
> On Mon, Dec 12, 2016 at 12:45 PM, Wayne DePrince Jr. <waynedpj at in-giro.xyz>
> wrote:
> 
> > ahoy all,
> > 
> > for parsing an [XSPF][1] document, the [specification][2] states that [a
> > `` element can have zero or more `` elements to define
> > the
> > URI of a resource to be rendered][3].  for example:
> > 
> > <?xml version="1.0" encoding="UTF-8"?>
> > http://xspf.org/ns/0/">;
> >   <trackList>
> >     <track>
> >       http://example.com/song_1.ogg</location>;
> >       http://mirror.xyz/example.com/song_1.ogg</location>;
> >     </track>
> >     <track
> >       http://example.com/song_2.ogg</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?  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?
> > 
> > thanks
> > 
> >   [1]: http://xspf.org
> >   [2]: http://xspf.org/xspf-v1.html
> >   [3]: http://xspf.org/xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.1
> > 
> > 
> > PS: also posted to StackExchange
> > 
> > https://stackoverflow.com/questions/41101769/multiple-
> > location-elements-per-track-in-xspf

-- 
http://waynedpj.in-giro.xyz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20161215/0322b4c4/attachment.html>