[Playlist] an alternate xspf over json implementation

[Fabricio Zuardi]

I agree that plural is better, for the cchits implementation it is in
singular just because I didnt needed more than one location per file
at the time and I was just matching 1-1 the xspf spec xml element
names. I don't think the json feeds on cchits are been used to a point
in which backwards compatibility should be a concern, it should be
fairly safe to just change everything to plurals.

And I will keep that in mind for the soon to come Ning music module ;P

[]s


On 5/13/07, Lucas Gonze <lgonze at panix.com> 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.
>
> > - the whole thing is under a "playlist" node
>
> I think that this question is purely in the JSON realm and should be
> defined by the JSON sub-committee, which I imagine would be you and
> Fabricio.  :)
>
> > - the track's media file url is stored as a string under "location",
> > rather than as an array of strings under "locations"
>
> I like the array of strings better, because it matches XSPF semantics
> more closely.  Being able to have multiple alternative sources is an
> important feature.
>
> > - similarly, there is an identifier, instead of identifiers
>
> ditto.  Plural is better.
>
> > JSPF - a JSON serialization of XSPF
> > vs
> > JSPF - JSON inspired by XSPF
>
>
> #1: a JSON serialization of XSPF *semantics*
>
> -Lucas
>
> _______________________________________________
> Playlist mailing list
> Playlist at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/playlist
>


-- 
Fabricio C Zuardi
http://cchits.org