[Playlist] an alternate xspf over json implementation

[Mike Linksvayer]

On Mon, May 14, 2007 at 12:49:16AM +0000, Lucas Gonze wrote:
> Chris Anderson wrote:
>  > I'm especially enamored of the license element, because json does not
>  > have the equivalent of attributes on elements, so rel does not work
>  > (although it can be simulated... at the expense of readability).
> 
> Yeah, I've been aware of Fabricio's license element since he did it. 
> This is a handy bit of metadata, but I don't think its so crucial that 
> we should do a new version of XSPF to incorporate it.  I would use the 
> link element and take the hit on readability.
> 
> Even so, what do you think the definition is?
> 
> 1) Is it purely presentational, like CSS?  That implies that it's 
> opaque/non-semantic data which is no more factual than a background 
> color or font style.
> 
> 2) Is it an assertion about the legal status of a third party resource? 
>   If so, who's doing the asserting?  Why should this little scrap of XML 
> be trusted on something with so much potential for trouble?
> 
> 3) Is it -- like the creator, album, title, and duration fields -- a 
> query string that can do double duty as metadata?
> 
> You might want to ask Creative Commons what they recommend.  I would do 
> that either by posting to the cc-licenses list or by privately emailing 
> the CC tech folk.

It is (2), but remove "third party" (i.e., just "a resource") and
don't worry about who is conveying the information.  Or rather, a
spec like XSPF shouldn't worry about it.  Much like any information
that may be conveyed by feeds (e.g.
http://wiki.creativecommons.org/Syndication) or even web pages, you
trust some people/sites and not others.  Sometimes you use the
format internally so there is no trust issue, but there is one of
shoving data around.  (2) merely is a subset of (3) and its explicitly
"legal" sounding nature doesn't make it magic.

Mike
(A CC tech folk posting from my personal email address because
that's what I'm subscribed to this list as.)