[Playlist] an alternate xspf over json implementation

[Lucas Gonze]

> Chris Anderson wrote:
>> Correct me if I'm wrong, but extension order does not matter in XSPF,
>> so perhaps the usability gains here outweigh the costs of losing XML
>> ordering.

Sebastian Pipping wrote:
> I'm not sure if extension order really is insignificant.
> The order of locations for example is significant and
> I don't see why it should be different with extensions.
> Lucas, does it matter? Is there a third way?

I could imagine that the rel and meta elements would need to preserve 
order, but because the extension element contains a complex structure 
with multiple nodes inside I don't think that the order of extensions 
should matter.

BTW, I notice a pattern with how much of our time we spend on the 
extension elements, which are not central to XSPF' mission, and which 
are relatively little used.  The attribution element matters a lot 
(because it enables sharing licenses which require attribution), but it 
gets much less time.  These extension elements are consistently on the 
wrong side of the 80/20 rule.

Sebastian Pipping wrote:
> I think we should not introduce additional features
> for JSPF. I think we should keep XSPF and JSON in sync.
> If we really need more features we should make a successor
> version of both JSON and XSPF in my eyes.

I strongly agree.  There is no bigger mistake.