[Playlist] Re: xspf over json

[Lucas Gonze]

>> On 4/28/07, Lucas Gonze <lgonze at panix.com <mailto:lgonze at panix.com>> 
>> wrote:
>> I have one misgiving about this project -- there is a risk that playlist
>> technology will split into JSON and XML factions, which would work
>> against interoperability.  

Jay Fienberg wrote:
> IMHO, formats like XSPF are more and more going to be treated as schemas 
> (and/or ontologies) that applications translate into convenient markup 
> document types (e.g., in XML), data stores (e.g., in SQL databases), and 
> object stores (e.g., in JSON). The ideal of representing a "format" in 
> XML is not going away, but there's definitely something of a post-XML 
> outlook influencing web and application developers, i.e., in terms of 
> storage, interchange and document formats.

That seems completely reasonable to me, so the question for our group is 
how we can manage this diaspora in such a way that we don't lose 
interoperability.

Our project has always been about shareability.  We want shareable media 
references, hence content resolution.  We want text which is shareable 
from one language context to another, hence the move from US-ASCII 
formats like M3U and RAM to charset-agnostic XML.  We want relative URLs 
to keep their integrity as playlist files move from one host to another, 
hence the XML Base section of the spec.

Indeed, the utility of XSPF in Grabb.it came directly from our success 
in that area, since they used XSPF because of the many independent media 
players that would give them access to.

So let's say there is going to be a split across dialects for data 
formats, with formats being ported to any or all of XML, JSON, RDF/XML, 
RDF/N3, semantic HTML, and Microformats (tm).  If XSPF is a schema 
and/or ontology with representations in a variety of technologies, how 
will developers interoperate?

My best answer is that there should continue to be a single interchange 
format, which I assume would be XML, but this would be complemented by 
libraries for converting to/from other format expression technologies. 
Developers would use whatever was convenient internally and only convert 
to XML at public interfaces.

Thoughts?

-Lucas