[Playlist] Re: xspf over json

Tue May 1 19:18:50 UTC 2007

Some comments embedded below, but to cut to the chase: I also think  
it's a good idea for "XSPF" to be the home of code and other  
information needed for converting between XSPF in its original XML  
form and in non-XML forms.

> Date: Sun, 29 Apr 2007 19:49:55 -0700
> From: Lucas Gonze <lgonze at panix.com>
>>> 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.

Interoperability is a kind-of loaded term. Behind it, there are a  
bunch of reasons why interoperability is an important goal. (And,  
though we don't all those reasons in front of us, I can guess what a  
bunch of them are, and agree that they are good reasons.)

"Interoperability" is also maybe loaded with different domains, e.g.,  
functional interoperability (how individual applications handle  
format differences), network interoperability (how a network  
interconnects through format differences), and cultural  
interoperability (how developers or users work in relationship to one  
and other around format differences).

XSPF is still a nascent effort whose goals could be thwarted by non- 
interoperability in each domain. But, XSPF is also in a great  
position to set a high standard of interoperability in each domain,  
i.e., XSPF can represent the full range of ideas, technologies and  
approaches that "playlist people" want and need.

> 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.

I personally think of XSPF as "SP" first and foremost--as "Shareable  
Playlists." And, I think this is the issue: "shareable" requires a  
high level of interoperability across all these domains. M3U and RAM  
were not so much about being shareable in any sense, and I think XSPF  
really strikes a chord in its emphasis on shareability.

> 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.

The "XML" in XSPF has given "SP" a well-embodied model of functional  
and network interoperability. In other words, XSPF in XML gives us  
something we can consistently use in a variety of applications and as  
part of the web link network.

> 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?

One thing to add here, which relates to your earlier comment about  
XML Base, too: XSPF, as a format, represents ideas about data,  
documents, and interactions. (Or, to say it with more jargon: it  
expresses data semantics, document semantics, and interaction  
semantics.)

So, it's conceivable that "shareable playlists" could be described in  
terms of each of these, and that each would be a factor in  
considering other representations of XSPF. For example, with JSPF, we  
could ask:

-does it represent the same ideas about what is playlist data
-does it represent the same ideas about what is a playlist document
-does it represent the same ideas about what are the key interactions  
playlists serve

It's natural that different formats are "lossy" in relation to  
others, and understanding the differences in terms of "lossy  
interoperability" instead of in terms of "lack of interoperability"  
could be advantageous. (Think of this as "Postel's Law" for formats.)  
And, conceivably, it could work both ways, e.g., JSPF is maybe a  
lossy version of XSPF, but XSPF is maybe a lossy version of XSPF+RDF.

> 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?

I think you are emphasizing XML as the public interface, in part, to  
serve network interoperability, i.e., every playlist producer /  
consumer becomes a network around the agreement that they can at  
least use XSPF as XML. But, one alternative way to serve this network  
is to imagine public web services that transform to and from XSPF,  
e.g. a JSPF-to-XSPF web service. If some producer only uses JSPF, a  
consumer can always get XSPF via plugging into the web service.

That said, I think, at this point, it's important to encourage  
everyone on the public web to produce / consume XSPF as XML, and wait  
and see until someone absolutely has a case where they see supporting  
XSPF in XML to be an unreasonable burden.

Jay

>
>> as in
>>> Jay Fienberg
>>>> http://jayfienberg.com
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/playlist/attachments/20070501/43c8fd32/attachment.htm