« Return to Thread: an alternate xspf over json implementation
Re: an alternate xspf over json implementation
by Lucas Gonze-2
::
Rate this Message:
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@...
http://lists.musicbrainz.org/mailman/listinfo/playlist
> 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@...
http://lists.musicbrainz.org/mailman/listinfo/playlist
« Return to Thread: an alternate xspf over json implementation
| Free embeddable forum powered by Nabble | Forum Help |
