[Playlist] an alternate xspf over json implementation

[Sebastian Pipping]

Chris Anderson wrote:
>> With mixed extension types we lose the extension order this
>> way, right? Is that order important to preserve?
> 
> I'm not sure I follow you here... I was imagining that if the
> extension for say "http://grabb.it" showed up twice in a track, it
> would show up as two elements of the "http://grabb.it" extension
> array. The order could be preserved, but I don't think there's any
> reason to need it to be. As far as the insides of the extensions go -
> that's up to individual applications.

--------------------------------------------------------------
I thought about this again. I modified your extension
proposal to actually see the difference:


== ORIGINAL ==
   "extension"     : {
     "http://example.application.com":[
       {"multiple":"instances of"},
       {"an application's":"extension can coexist"}
     ],
     "http://another.application.com":[{"each instance":"arbitrary json"}]
   }

== MOD ==
   "extension"     : [
     { "http://example.com/app/1/" : ARBITRARY_EXTENSION_BODY },
     { "http://example.com/app/2/" : ARBITRARY_EXTENSION_BODY }
   ]


I like the latter much better because
* It fully preserves the order (ABABA will not become AAABB)
* It is simpler, has one level nesting less (in a way "list versus tree")

I finishes the draft in the wiki with that new extension model.
If I didn't overlook anything the at-this-moment JSPF proposal can be
converted back and forth losslessly. In my eyes it also is pretty
readable. What do you think?


Before I forget: If you look at the track locations you find this:

   "location"      : [
     {"location"     : "http://example.com/1/"},
     {"location"     : "http://example.com/2/"}
   ],

It might look a little starnge first, but...
I did it to be consistent to playlist.attribution:

   "attribution"   : [
     {"identifier"   : "http://example.com/"},
     {"location"     : "http://example.com/"}
   ],

We need a key name for it anyway. Also I decided not to append
"s"s to the "container elements" to keep the names 1:1 XSPF.
Additionally we have singular everywhere then. Simplicity,
consistency, readability. Well, in my eyes. I hope you like it.



Sebastian