[microformats-discuss] Re: playlist microformat

[Chris Messina]

Seems to me one application that we should not only consider applying
our work to, but possibly also reverse engineering for a functional
use of the microformat is iTunes2Web
(http://www.aarone.org/iTunes2Web/).

Imagine taking your iTunes library, exported as XML, and then
converting it to semantic XHTML. Then give it a UI like this by
applying some crazy JavaScript or XSLT:

http://www.aarone.org/iTunes2Web/example/

There's no reason why our MF wouldn't allow us to do this.... right?

Chris

On 9/9/05, Lucas Gonze <lucas.gonze at gmail.com> wrote:
> On 9/9/05, Chris Messina <chris.messina at gmail.com> wrote:
> > I wanted to chime in briefly at the meta level (ayuck) to try to help
> > the hPlaylist discussion evolve productively, in a way that's most
> > supportive of the microformat mission.
> 
> Thanks!  But also, don't forget the playlist mission.
> 
> > * My second point is that microformats are supposed to be used like
> > building blocks (that's what the logo was designed to look like, FYI).
> > So in this case, there seems to be little value in reinventing XOXO
> > just to make a flat outline for media.
> 
> I can't really picture what a XOXO implementation would look like.
> Any chance you could provide sample markup of XSPF semantics using a
> XOXO wrapper?
> 
> > * On top of that, we're really discussing two separate tasks here. The
> > first is marking up a series of items in a specific order -- i.e., a
> > "playlist." The second aspect is marking up media items like movies,
> > mp3s, images and so on. These are typically binary objects that need
> > to be described externally and linked to remotely. Those items need
> > not be found in playlists to be useful, so really we're describing two
> > separate microformats.
> 
> That's an interesting and worthwhile point.  I can picture a separate
> hTrack concept, with the caveat that I have to see the details to be
> confident that it will work.
> 
> > * And, as David has pointed out, the playlist spec should be
> > universally useful and not simply apply to mp3esque media files.
> > Although the work so far suggests that hPlaylist apply specifically to
> > mp3-style lists where ID3 + m3u might have sufficed before, we're
> > seeing combination playlists now that represent songs, music videos
> > and digital booklets
> > (http://www.flickr.com/photos/factoryjoe/41771361/). The hPlaylist
> > work should accommodate this -- as well as, for example, the work
> > being done on H20 playlists (h2obeta.law.harvard.edu).
> 
> I differ on this.  If it's not timed media, it's a distraction that we
> can't afford.
> 
> - Lucas
> 
> (I'll be away from my office for the next couple weeks, so will be
> extra slow to respond).
>