[Playlist] question about the XSPF specs

Tue Oct 20 09:53:47 UTC 2020

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.

4.1.1.2.14.1.1.1.11 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 ?
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.
>
> 4.1.1.2.8 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.4.1.1.2.14.1.1.1.6
>>>>>>
>>>>>> 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/20201020/23cefe8c/attachment.html>