[Playlist] question about the XSPF specs

Wed Nov 25 08:07:46 UTC 2020

>
> 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/20201125/ca7d4237/attachment.html>