[Playlist] question about the XSPF specs

Wed Nov 16 09:18:14 UTC 2022

Hi everyone,
I'm still wondering if any update of the XSPF/JSPF specs are planned.
Among others, it would be nice to handle stream links (that are somewhere
between the link attribute and the location attribute)

I'm still developing my music website based on your standard:
https://www.spiff-radio.org/

Thanks

Benoît

Le mer. 25 nov. 2020 à 09:07, Benoît Gréant <gordie.lachance at gmail.com> a
écrit :

> Well, that page doesn't have a duration, so it can't be a location. But I
>> wonder whether it can be an identifier.
>
> So it should be a track link
> <https://xspf.org/orig-xspf-v1.html#rfc.section.4.1.1.2.14.1.1.1.11> ?
> How should I write it ?
>
>
>> How come you feel that wouldn't be a good fit?
>
> As I understand it, a Canonical ID must be a unique reference to a track.
> Is it ?
> That's the case for Spotify or Musicbrainz IDs.
> But how should we handle this for Youtube ? That might have 50 uploads of
> the same tracks, so 50 different IDs ?
>
> Thanks !
>
> Benoît
>
> Le mar. 24 nov. 2020 à 23:12, Lucas Gonze <lucas at gonze.com> a écrit :
>
>> 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>
>> wrote:
>>
>>> 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 ?
>>>
>>
>> Well, that page doesn't have a duration, so it can't be a location. But I
>> wonder whether it can be an identifier.
>>
>> 4.1.1.2.14.1.1.1.2 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.
>>>>
>>>> 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/20221116/ac01aab5/attachment-0001.htm>