resolving multiple <location> elements per <track> in XSPF?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

resolving multiple <location> elements per <track> in XSPF?

Wayne DePrince Jr.
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/">
  <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?  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



PS: also posted to StackExchange



--
http://waynedpj.in-giro.xyz

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.xiph.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: resolving multiple <location> elements per <track> in XSPF?

Lucas Gonze-2
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. <[hidden email]> wrote:
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/">
  <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?  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



PS: also posted to StackExchange




_______________________________________________
Playlist mailing list
[hidden email]
http://lists.xiph.org/mailman/listinfo/playlist



_______________________________________________
Playlist mailing list
[hidden email]
http://lists.xiph.org/mailman/listinfo/playlist
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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#.3Cplaylist.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. <[hidden email]>
wrote:

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/">;
  <trackList>
    <track>
    </track>
    <track
    </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



PS: also posted to StackExchange

location-elements-per-track-in-xspf

-- 
http://waynedpj.in-giro.xyz

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.xiph.org/mailman/listinfo/playlist
Loading...