[Playlist] question about the XSPF specs

Lucas Gonze lucas at gonze.com
Tue Nov 24 22:12:23 UTC 2020

Sorry to be slow. I am thinking about the place of the open web, open
standards, and openness in music, as a prerequisite to thinking of what I
want to achieve with open playlists.

On Tue, Oct 20, 2020 at 2:54 AM Benoît Gréant <gordie.lachance at gmail.com>

> So, what do you think of it ? :)
> +, I still would like to know how to add "regular" links (not audio
> sources, not identifiers) to an XSPF track with the current specs.
> link
>> The link element allows XSPF to be extended without the use of XML
>> namespaces. xspf:track elements MAY contain zero or more link elements.
>> <link rel="http://foaf.org/namespace/version1">
>> http://socialnetwork.org/foaf/mary.rdfs</link>
> Let's say I have this link
> <a href="https://fr.wikipedia.org/wiki/Karma_Police">Karma Police on
>> Wikipedia</a>
> How should I convert this to an XSPF track link ?

Well, that page doesn't have a duration, so it can't be a location. But I
wonder whether it can be an identifier. identifier

Canonical ID for this resource. Likely to be a hash or other
location-independent name, such as a MusicBrainz identifier. MUST be a
legal URI. xspf:track elements MAY contain zero or more identifier elements.
How come you feel that wouldn't be a good fit?

> Thanks !!
> Benoît
> Le dim. 18 oct. 2020 à 21:04, Benoît Gréant <gordie.lachance at gmail.com> a
> écrit :
>> Lucas,
>> Here's some of my thoughts.  Most of them are related to the new way
>> people do listen to music : often from Spotify, or on some other services,
>> where the playlists are constantly updated and don't have audio files but
>> stream links.
>> *Stream sources*
>> There is something to do about the location and the links attribute.
>> A track could have some locations (audio files) and links (eg. wikipedia
>> entry), but where should I put stream sources (links to spotify, youtube,
>> apple music, ...) ?
>> It looks like they don't fit any category.  + sometimes, a stream source
>> is available in one country but not in another.
>> Maybe we would need a new attribute here for those stream sources.
>> Also, it would be great to be able to set not only URLs for them
>> (files/links/streams), but a title.
>> It's a bit weird to display some URLs without knowing what will be opened
>> behind.
>> I could have a script that would request every URL to get a title, but
>> well, that would be a lot of requests for a playlist.
>> So maybe all those attributes (location/link/stream) could have both an
>> URL and a title. And why not even more...
>> *Total tracks*
>> When I fetch a playlist (eg. Spotify API), i will get X tracks back,
>> depending of their API. Spotify has a 100 tracks limit.
>> But they do return the number of total tracks.
>> So we could have an XSPF playlist that contains 100 tracks but  knowing
>> that there is more to load.
>> date
>> *Creation date (not last-modified date) of the playlist, formatted as a
>> XML schema dateTime. xspf:playlist elements MAY contain exactly one.*
>> The current attribute is for the creation date, but it would be useful to
>> have an *updated date*.  Most playlists now, on Spotify or such, are
>> constantly updated.  It would be nice to have their creation time but also
>> their last modified time.
>> In the same idea, I would personally like to have an attribute for *expiration
>> date* (time).
>> Why ? My app (for instance) currently loads XSPF playlists and do refresh
>> them every X time.
>> A playlist generated from a radio station would refresh after 5 minutes
>> because it contains only 5 tracks.
>> But a curated playlist on Spotify would be refreshed every, let's say, 1
>> day; depending on its activity.
>> It would be cool to be able to set an expiry time.
>> That's all I see for now, what do you think of it ?
>> Thanks for your interest.
>> Benoît
>> Le ven. 18 sept. 2020 à 01:51, Benoît Gréant <gordie.lachance at gmail.com>
>> a écrit :
>>> Hi Lucas,
>>> First, thanks a lot for your kind reply and interest.
>>> Maybe the best would be that I take some time to compile all my
>>> questions.
>>> I don't really know how I can help, except by giving some feedback.
>>> Just thought that it would be nice to update the standard since the music
>>> industry changed a lot those years with the streaming industry.
>>> A chat would be easier for me since i'm quite OK to write english but
>>> it's more difficult for me to speak :)
>>> Thanks !
>>> Benoît
>>> Le ven. 18 sept. 2020 à 00:50, Lucas Gonze <lucas at gonze.com> a écrit :
>>>> Benoît, how can I help you out with this? Would a real time chat or
>>>> zoom be helpful?
>>>> If so, is anybody else interested in participating?
>>>> On Mon, Sep 14, 2020 at 2:22 PM Lucas Gonze <lucas at gonze.com> wrote:
>>>>> I agree. It would be a productive project, and probably not too hard.
>>>>> On Benoit's ideas about how to do what he's thinking about, I wonder
>>>>> if other people think that it would be wise to have a track with multiple
>>>>> location elements, each pointing to a different streaming service. That
>>>>> would function similarly to the sources idea:
>>>>> "sources": [
>>>>> 'https://open.spotify.com/track/3FgDF8tNn6aqB7ycygy7ch',
>>>>> 'https://www.youtube.com/watch?v=PA3P1-aSvKQ',
>>>>> 'https://www.youtube.com/watch?v=vUes9-tFWm4',
>>>>> ]
>>>>> Then, Benoit brought up the issue of having different metadata for
>>>>> each track.location or track.sources[i], like this:
>>>>> >>
>>>>>      "meta"          : [
>>>>>        {'wpsstmapi/input_url'=> 'myvalue1'},
>>>>>        {'wpsstmapi/xspf_url'=> 'myvalue2'},
>>>>>        {'wpsstmapi/importer_slug'=> 'myvalue3'},
>>>>>      ],
>>>>> In the specs, the keys are urls like http://example.com/rel/1/.
>>>>> Should this point to an URL that exists or can I use what I want ?
>>>>> <<
>>>>> The URL does not have to exist. This is legal, even though there is
>>>>> not actually any domain at example.org:
>>>>> <track><meta rel="http://example.org/meta/track/vendornick
>>>>> ">Spotify</meta></track>
>>>>> Over the years I have softened up quite a lot towards namespaces, and
>>>>> don't think something like this would be a bad thing:
>>>>> <track><location ns:vendornick="Spotify">
>>>>> https://open.spotify.com/track/3FgDF8tNn6aqB7ycygy7ch
>>>>> </location></track>
>>>>> On Mon, Sep 14, 2020 at 2:01 PM Martin McEvoy <
>>>>> martin at weborganics.co.uk> wrote:
>>>>>> +1 from me on a JSON version.
>>>>>> On Tue, 24 Mar 2020, 17:13 Lucas Gonze, <lucas at gonze.com> wrote:
>>>>>>> Benoît, it's excellent to meet you. I am CC'ing the XSPF list at
>>>>>>> playlist at xiph.org and copying this answer to the Stack Overflow
>>>>>>> thread.
>>>>>>> The info element is designed to do what you need:
>>>>>>> http://xspf.org/xspf-v1.html#rfc.section.
>>>>>>> However, there can only be one info element per track.
>>>>>>> Regarding the many years since the last update of the spec, maybe
>>>>>>> it's time to do one. A blessed JSON version would be useful.
>>>>>>> -Lucas
>>>>>>> On Tue, Mar 24, 2020 at 1:38 AM Benoît Gréant <
>>>>>>> gordie.lachance at gmail.com> wrote:
>>>>>>>> Hi guys !
>>>>>>>> I love your XSPF thing :)
>>>>>>>> Have been playing with it since several years, using it as base for
>>>>>>>> my website (&API
>>>>>>>> <https://www.spiff-radio.org/wordpress-soundsystem-plugin/soundsystem-api/>,
>>>>>>>> &WP plugin) spiff-radio.org.
>>>>>>>> I have a small question.  I want to attach (several) links to a
>>>>>>>> playlist track (eg. spotify/youtuble/apple music...); what tag should I use
>>>>>>>> for this ?
>>>>>>>> Well, I posted the complete question on Stackoverflow
>>>>>>>> <https://stackoverflow.com/questions/60822682/xspf-xml-playlist-specifications-how-should-i-format-links-to-one-or-several>
>>>>>>>> .
>>>>>>>> Thanks for your help.
>>>>>>>> Benoît
>>>>>>> _______________________________________________
>>>>>>> Playlist mailing list
>>>>>>> Playlist at xiph.org
>>>>>>> http://lists.xiph.org/mailman/listinfo/playlist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20201124/7aa70fa2/attachment.html>

More information about the Playlist mailing list