[Playlist] an alternate xspf over json implementation

[Chris Anderson]

Sebastian Pipping <webmaster at hartwork.org> wrote:
> -----------------------------------------------------------
> I disagree here. I think we should cover the full XSPF
> feature spectrum and try to make that look best.
> -----------------------------------------------------------

I'm hopeful that we can make JSPF a peer to XSPF, but I'm worried that
if we start with full spectrum implementation, we could end up making
the most commonly used elements more complex than they have to be. I'd
rather keep them simple at the expense of a little extra complexity in
the less commonly used elements. Perhaps we won't have to make that
tradeoff, and  we'll be able to keep it all as simple as possible.
Once again, we're lucky that we're not making a general purpose XML ->
JSON convertor.


> The article on XML.com was quite interesting.
> The "element order doesn't matter" thing hits our
> attribution element. I currently think of something
> like this as a possible solution:
>
>   "attribution" : {
>     "1" : {
>       "type" : "identifier",
>       "uri" : "http://www.example.com/"
>     },
>     "2" : {
>       "type" : "location",
>       "uri" : "http://www.example.com/"
>     }
>   }

Here's another way to do it, preserving order:
{
  "attribution" : [
    {"identifier":"http://www.example.com/"},
    {"location":"http://www.example.com/"}
  ]
}


> I don't want
> people saying "no, the JSON edition cannot do that"
> in the future. Let's create a sibling, not a child of XSPF.

I agree with the goal - I'd just put readability ahead of feature
parity on the priorities list. It's probably good that we're coming
from different angles on this, hopefully we'll get a complete and
readable format!

Chris