[Playlist] an alternate xspf over json implementation

[Chris Anderson]

On 6/13/07, Sebastian Pipping <webmaster at hartwork.org> wrote:
> Chris Anderson wrote:
> > I'm not sure how one would spec a JSON format. I'm sure it can be done
> > - but some of the key differences from XML are that a JSON format
> > ought to allow arbitrary keys to be added to the document, as long as
> > the required keys are present and any keys that are part of the spec
> > are valid.
>
> ---------------------------------------------
> This conflicts to the extension concept
> of XSPF. While I'm not sure which concept
> is better, I think we should try to
> make the semantics of JSPF as close to
> that of XSPF to be able to convert from
> JSPF to XSPF without problems.
>

I understand what you are getting at here. From [1]: "The JSON
approach of just ignoring keys you don't understand can get you a long
way, but I don't think it scales."

Probably the best course of action is for the JSPF spec to remain
silent on the issue. Conversion from the Javascript object to an XSPF
document will by its nature ignore keys that aren't needed, so the
only need for the spec to disallow extra keys would be to ease
manipulations of the JSPF that don't first read it into a data
structure. Stream parsing JSPF directly, rather than explictly as JSON
first, seems an edge case to me.

The standard JSON behavior is to parse the whole document into a data
structure. Code which is expecting a JSPF structure won't be bothered
by extra keys, so it's convention in JSON to allow those keys.

[1] http://blog.jclark.com/2007/04/xml-and-json.html

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