an alternate xspf over json implementation

[Chris Anderson-4]

Fabricio Zuardi has been using a xspf-ish json document at CCHits,
which you can look at here. The differences between his and the one
we're using for Grabb.it are very slight:

 - the whole thing is under a "playlist" node
 - the track's media file url is stored as a string under "location",
rather than as an array of strings under "locations"
 - similarly, there is an identifier, instead of identifiers
 - there is a "license" key for each track, with a url to relevant license.

here is an example:

http://cchits.ning.com/recent/?fmt=json&var=cchitsPlaylist

I'm especially enamored of the license element, because json does not
have the equivalent of attributes on elements, so rel does not work
(although it can be simulated... at the expense of readability).

I'm starting to see some parallels between json and xml: In xml, when
you need to add more content than a particular standard allows, you
can bring in an additional namespace. In json, you can just add
elements that are not specified by the standard. Parsers will ignore
those elements, and players will gracefully degrade the experience, as
long as a bare minimum of information is in the standard elements. I
guess this tends toward "tag soup" / "associative array soup" :) as
accepting this pattern obviates the need for things like XSPFs
extension namespace.

... I'm getting kinda abstract here ... maybe this is better suited to
a javascript / json list.

But you all have a history of well reasoned opinions about standard
formats, so I guess the takehome question is - Is it better to support
the "license" element, despite its absense from the XSPF spec, in
favor of compactness and readability (the json way), or is it better
to stay as close to XSPF v1 as possible?

I guess this question was bound to come up eventually, and it has
practical implications now, as I'd really like to start propagating
Creative Commons info out to the browser on Grabb.it playlists.

JSPF - a JSON serialization of XSPF
vs
JSPF - JSON inspired by XSPF

Thanks for feedback!

--
Chris Anderson
http://jchris.mfdz.com

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Agentbleu]

I would like to submit a new site I have just launched into beta, to  
be listed on xspf.

here would be the submission

Website:

<a href='http://www.myplaylist.biz">MyPlayList</a><br>
<p>Combining picture playlists built using the Flickr API in xspf  
with music playlists both in xspf format.


I would very much welcome any comments or criticism, this is my first  
dive into xspf and am still finding my way about.

many thanks
steve

> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Chris Anderson-4]

Steve,
I like the site - from your example link it looks promising. However I
was thrown off after signing up when it asked me to enter the url of
my project playlist page...

Perhaps if there were an option to enter the endpoint url of any xspf
file on the internet. eg. http://mfdz.com/jchris.xspf etc.

It's cool that you can resolve project playlist primary keys to xspf
files, but it requires that you have a project playlist node you want
to import. I've played with that site a little, but it really only
represents the tip of the iceberg as far as available playlists.

Chris

On 5/13/07, Agentbleu <colourbleu@...> wrote:

> I would like to submit a new site I have just launched into beta, to
> be listed on xspf.
>
> here would be the submission
>
> Website:
>
> <a href='http://www.myplaylist.biz">MyPlayList</a><br>
> <p>Combining picture playlists built using the Flickr API in xspf
> with music playlists both in xspf format.
>
>
> I would very much welcome any comments or criticism, this is my first
> dive into xspf and am still finding my way about.
>
> many thanks
> steve
>
> > _______________________________________________
> > Playlist mailing list
> > Playlist@...
> > http://lists.musicbrainz.org/mailman/listinfo/playlist
>
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

--
Chris Anderson
http://jchris.mfdz.com

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Agentbleu]

Hi Chris

Many thanks for your suggestion. I have now added that feature and  
would welcome you to go back and try again. You can now enter any  
playlist you have. Hopefully it all works.

I will also add the possibility to crawl other xspf playlist compiler  
sites, I found one called
http://www.plurn.com/
that looks like it's compatible with what I have now,

But I would welcome suggestions of other such sites that I should try  
to incorporate.

thanks again for any thoughts.
steve

On 13 May 2007, at 10:24, Chris Anderson wrote:

> Steve,
> I like the site - from your example link it looks promising. However I
> was thrown off after signing up when it asked me to enter the url of
> my project playlist page...
>
> Perhaps if there were an option to enter the endpoint url of any xspf
> file on the internet. eg. http://mfdz.com/jchris.xspf etc.
>
> It's cool that you can resolve project playlist primary keys to xspf
> files, but it requires that you have a project playlist node you want
> to import. I've played with that site a little, but it really only
> represents the tip of the iceberg as far as available playlists.
>
> Chris
>
> On 5/13/07, Agentbleu <colourbleu@...> wrote:
>> I would like to submit a new site I have just launched into beta, to
>> be listed on xspf.
>>
>> here would be the submission
>>
>> Website:
>>
>> <a href='http://www.myplaylist.biz">MyPlayList</a><br>
>> <p>Combining picture playlists built using the Flickr API in xspf
>> with music playlists both in xspf format.
>>
>>
>> I would very much welcome any comments or criticism, this is my first
>> dive into xspf and am still finding my way about.
>>
>> many thanks
>> steve
>>
>> > _______________________________________________
>> > Playlist mailing list
>> > Playlist@...
>> > http://lists.musicbrainz.org/mailman/listinfo/playlist
>>
>>
>> _______________________________________________
>> Playlist mailing list
>> Playlist@...
>> http://lists.musicbrainz.org/mailman/listinfo/playlist
>>
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Agentbleu wrote:
> here would be the submission
>
> Website:
>
> <a href='http://www.myplaylist.biz">MyPlayList</a><br>
> <p>Combining picture playlists built using the Flickr API in xspf with
> music playlists both in xspf format.

---------------------------------------------------
Online in about 15 minutes.

Would be cool if you could add a link to
the XSPF file used inside. That would enable
users to see through to the content if
they like.



Sebastian

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Agentbleu]

Thanks Sebastian

I have been thinking of how best to display the content, most elegantly.
a see through to the xspf file would be useful anyway, so  i will add  
that.

I was thinking more about displaying a small sample of the tracks  
names, along with a few of the pictures, in the playlists, and them  
tagging them with either the picture search words as tags or letting  
users add tags.

any more thoughts would be great.

steve


On 13 May 2007, at 19:46, Sebastian Pipping wrote:

> Agentbleu wrote:
>> here would be the submission
>>
>> Website:
>>
>> <a href='http://www.myplaylist.biz">MyPlayList</a><br>
>> <p>Combining picture playlists built using the Flickr API in xspf  
>> with
>> music playlists both in xspf format.
>
> ---------------------------------------------------
> Online in about 15 minutes.
>
> Would be cool if you could add a link to
> the XSPF file used inside. That would enable
> users to see through to the content if
> they like.
>
>
>
> Sebastian
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze-2]

Chris Anderson wrote:
 > I'm especially enamored of the license element, because json does not
 > have the equivalent of attributes on elements, so rel does not work
 > (although it can be simulated... at the expense of readability).

Yeah, I've been aware of Fabricio's license element since he did it.
This is a handy bit of metadata, but I don't think its so crucial that
we should do a new version of XSPF to incorporate it.  I would use the
link element and take the hit on readability.

Even so, what do you think the definition is?

1) Is it purely presentational, like CSS?  That implies that it's
opaque/non-semantic data which is no more factual than a background
color or font style.

2) Is it an assertion about the legal status of a third party resource?
  If so, who's doing the asserting?  Why should this little scrap of XML
be trusted on something with so much potential for trouble?

3) Is it -- like the creator, album, title, and duration fields -- a
query string that can do double duty as metadata?

You might want to ask Creative Commons what they recommend.  I would do
that either by posting to the cc-licenses list or by privately emailing
the CC tech folk.

> - the whole thing is under a "playlist" node

I think that this question is purely in the JSON realm and should be
defined by the JSON sub-committee, which I imagine would be you and
Fabricio.  :)

> - the track's media file url is stored as a string under "location",
> rather than as an array of strings under "locations"

I like the array of strings better, because it matches XSPF semantics
more closely.  Being able to have multiple alternative sources is an
important feature.

> - similarly, there is an identifier, instead of identifiers

ditto.  Plural is better.

> JSPF - a JSON serialization of XSPF
> vs
> JSPF - JSON inspired by XSPF


#1: a JSON serialization of XSPF *semantics*

-Lucas

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Chris Anderson-4]

On 5/13/07, Lucas Gonze <lgonze@...> wrote:

>
> Even so, what do you think the definition is?
>
> 1) Is it purely presentational, like CSS?  That implies that it's
> opaque/non-semantic data which is no more factual than a background
> color or font style.
>
> 2) Is it an assertion about the legal status of a third party resource?
>   If so, who's doing the asserting?  Why should this little scrap of XML
> be trusted on something with so much potential for trouble?
>
> 3) Is it -- like the creator, album, title, and duration fields -- a
> query string that can do double duty as metadata?
>
> You might want to ask Creative Commons what they recommend.  I would do
> that either by posting to the cc-licenses list or by privately emailing
> the CC tech folk.

I agree, it is a _tough_ question. I'd say that its a semantic
assertion, but one that must be taken with a grain of salt, depending
on who is generating the xspf. Some content servers allow users to
specify a release license (mfdz.com) and some mandate creative commons
(ccmixter). In those cases, where the license is asserted so close to
the user's preference being stated, the XML can be trusted as well as
any other source. In the case of resyndication, someone relying on the
license would do well to check back up the chain - eg. Grabb.it could
assert a creative commons license, but we're not infallible. It would
be best in that case to follow the "info" url to the original source.

As far as searching and metadata go, I think it qualifies as both. I
can imagine two songs being distinguished by license - for instance an
intrumental version may forgo the copyright associate with its lyrics,
etc. If the title doesn't specify 'instrumental', the license may be
the best disambiguator.

Good suggestion to check with CC!

Chris

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Mike Linksvayer]

On Mon, May 14, 2007 at 12:49:16AM +0000, Lucas Gonze wrote:

> Chris Anderson wrote:
>  > I'm especially enamored of the license element, because json does not
>  > have the equivalent of attributes on elements, so rel does not work
>  > (although it can be simulated...@the expense of readability).
>
> Yeah, I've been aware of Fabricio's license element since he did it.
> This is a handy bit of metadata, but I don't think its so crucial that
> we should do a new version of XSPF to incorporate it.  I would use the
> link element and take the hit on readability.
>
> Even so, what do you think the definition is?
>
> 1) Is it purely presentational, like CSS?  That implies that it's
> opaque/non-semantic data which is no more factual than a background
> color or font style.
>
> 2) Is it an assertion about the legal status of a third party resource?
>   If so, who's doing the asserting?  Why should this little scrap of XML
> be trusted on something with so much potential for trouble?
>
> 3) Is it -- like the creator, album, title, and duration fields -- a
> query string that can do double duty as metadata?
>
> You might want to ask Creative Commons what they recommend.  I would do
> that either by posting to the cc-licenses list or by privately emailing
> the CC tech folk.

It is (2), but remove "third party" (i.e., just "a resource") and
don't worry about who is conveying the information.  Or rather, a
spec like XSPF shouldn't worry about it.  Much like any information
that may be conveyed by feeds (e.g.
http://wiki.creativecommons.org/Syndication) or even web pages, you
trust some people/sites and not others.  Sometimes you use the
format internally so there is no trust issue, but there is one of
shoving data around.  (2) merely is a subset of (3) and its explicitly
"legal" sounding nature doesn't make it magic.

Mike
(A CC tech folk posting from my personal email address because
that's what I'm subscribed to this list as.)

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze-2]

First shot at an extension for licenses in tracks:

http://gonze.com/xspf/rellicense/

I don't plan to keep that at my personal web site.  That is just a
convenience for posting this early strawman.  If it passes muster, it
should probably live at xspf.org.



_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Lucas Gonze wrote:
> First shot at an extension for licenses in tracks:
>
> http://gonze.com/xspf/rellicense/
>
> I don't plan to keep that at my personal web site.  That is just a
> convenience for posting this early strawman.  If it passes muster, it
> should probably live at xspf.org.

-------------------------------------------------------------
Had a first look - nice!

How about one of these for the URI?:
 * http://xspf.org/track/license/
 * http://xspf.org/track/link/license/1/0/



Sebastian


_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Chris Anderson-4]

It would definitely be nice to have a cannonical rel uri for this
stuff. What you have looks great.

As part of supporting licenses for Grabb.it, I'll eventually be doing
a survey of how they appear in the wild. So far, some are in link
tags, some in meta tags, and they use a mix of web.resource.org uris
and creativecommons.org uris for the rel. When they use the
creativecommons uris, they tend to put the same uri in the rel as is
in the element text. More detail to follow.

I've got a few notions on how to handle these in JSPF without
resorting to a custom tag. You'll hear more when I have an
implementation.

Spent the last few days at RailsConf, it was definitely a blast but
now I need a few days to recover
. :)

Chris

On 5/21/07, Sebastian Pipping <webmaster@...> wrote:

> Lucas Gonze wrote:
> > First shot at an extension for licenses in tracks:
> >
> > http://gonze.com/xspf/rellicense/
> >
> > I don't plan to keep that at my personal web site.  That is just a
> > convenience for posting this early strawman.  If it passes muster, it
> > should probably live at xspf.org.
>
> -------------------------------------------------------------
> Had a first look - nice!
>
> How about one of these for the URI?:
>  * http://xspf.org/track/license/
>  * http://xspf.org/track/link/license/1/0/
>
>
>
> Sebastian
>
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

--
Chris Anderson
http://jchris.mfdz.com

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Fabricio Zuardi]

I agree that plural is better, for the cchits implementation it is in
singular just because I didnt needed more than one location per file
at the time and I was just matching 1-1 the xspf spec xml element
names. I don't think the json feeds on cchits are been used to a point
in which backwards compatibility should be a concern, it should be
fairly safe to just change everything to plurals.

And I will keep that in mind for the soon to come Ning music module ;P

[]s


On 5/13/07, Lucas Gonze <lgonze@...> wrote:

> Chris Anderson wrote:
>  > I'm especially enamored of the license element, because json does not
>  > have the equivalent of attributes on elements, so rel does not work
>  > (although it can be simulated... at the expense of readability).
>
> Yeah, I've been aware of Fabricio's license element since he did it.
> This is a handy bit of metadata, but I don't think its so crucial that
> we should do a new version of XSPF to incorporate it.  I would use the
> link element and take the hit on readability.
>
> Even so, what do you think the definition is?
>
> 1) Is it purely presentational, like CSS?  That implies that it's
> opaque/non-semantic data which is no more factual than a background
> color or font style.
>
> 2) Is it an assertion about the legal status of a third party resource?
>   If so, who's doing the asserting?  Why should this little scrap of XML
> be trusted on something with so much potential for trouble?
>
> 3) Is it -- like the creator, album, title, and duration fields -- a
> query string that can do double duty as metadata?
>
> You might want to ask Creative Commons what they recommend.  I would do
> that either by posting to the cc-licenses list or by privately emailing
> the CC tech folk.
>
> > - the whole thing is under a "playlist" node
>
> I think that this question is purely in the JSON realm and should be
> defined by the JSON sub-committee, which I imagine would be you and
> Fabricio.  :)
>
> > - the track's media file url is stored as a string under "location",
> > rather than as an array of strings under "locations"
>
> I like the array of strings better, because it matches XSPF semantics
> more closely.  Being able to have multiple alternative sources is an
> important feature.
>
> > - similarly, there is an identifier, instead of identifiers
>
> ditto.  Plural is better.
>
> > JSPF - a JSON serialization of XSPF
> > vs
> > JSPF - JSON inspired by XSPF
>
>
> #1: a JSON serialization of XSPF *semantics*
>
> -Lucas
>
> _______________________________________________
> Playlist mailing list
> Playlist@...
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>

--
Fabricio C Zuardi
http://cchits.org

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Sebastian Pipping-3]

Sorry for not coming to this earlier, but I guess we still
have to define an official JSPF format. From what I have
seen here

   http://jchris.mfdz.com/jspf/xspf_parser_spec.html

and here

   http://cchits.ning.com/recent/?fmt=json&var=cchitsPlaylist

both formats are good work but do not seem fully XSPF compatible
to me, thinking of several extension "instances" with the very
same URI for example. (Does JSON allow key overloading?)

To not end up in interoperability hell I suggest we come
together again and create *the* JSON derivate of XSPF.
Who's with me?



Sebastian



_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Saoshyant]

On 6/12/07, Sebastian Pipping <webmaster@...> wrote:
> To not end up in interoperability hell I suggest we come
> together again and create *the* JSON derivate of XSPF.
> Who's with me?

As the XSPF Project Manager, I agree this should be done.

Let's start a page at the wiki, or something like that.

-Ivo

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Lucas Gonze-2]

Ivo Emanuel Gonçalves wrote:
> On 6/12/07, Sebastian Pipping <webmaster@...> wrote:
>> To not end up in interoperability hell I suggest we come
>> together again and create *the* JSON derivate of XSPF.
>> Who's with me?
>
> As the XSPF Project Manager, I agree this should be done.
>
> Let's start a page at the wiki, or something like that.

Agreed on all fronts.

-L

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist

[Chris Anderson-4]

I've been a little quiet on the front lately - the Grabb.it launch has
been all-consuming.

It seems to me that the principle challenge and constraint in defining
JSPF will be ensuring readability. If we consider JSPF to be the
gateway drug into using XSPF for more demanding applications, then
we'll have to work hard to design a format that is useful, readable,
and appealing.

While lossless XML -> JSON conversion is possible, the results look
more like a meditation on the capabilities of XML, than like a
convenient serialization of the salient aspects of the data being
modeled. [1]

I did a google-dive to find some of the articles I'd been reading when
originally working on JSPF, and tagged the best. [2]

Because we have the luxury of working with the XSPF data model, we
don't have to follow a general purpose conversion, except insofar as
XSPF allows arbitrary XML to be included.

How to proceed? Perhaps we should figure out what the "core" data
fields are of XSPF (perhaps those elements without attributes), and
build the basic JSPF format from them (some intersection of Fabricio's
and my work probably hits this sweet spot). Once we have these "core"
fields worked out, we can start to add the richer fields.

[1] http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html
[2] http://del.icio.us/jchris/json

--
Chris Anderson
http://jchris.mfdz.com

_______________________________________________
Playlist mailing list
Playlist@...
http://lists.musicbrainz.org/mailman/listinfo/playlist