Thanks, Manu!
The summary of my main suggestions gleaned from implementing hAudio
goes like this: (1) the item option may be unnecessary, (2) it would
be great to formalize htrack compatibility as a minimal, hand-codeable
option.
Here are the details:
(1) The playlisting case for which the hAudio/item option in the spec
was designed wasn't flexible enough to handle my situation, i.e. I
needed to put other data inside each blog item that doesn't adhere to
the spec (for example, the actual blog posts themselves and some
embedded player stuff). That's why I ended up marking up each post as
an independent hAudio despite the fact that they are very clearly an
ordered playlist. From a parser point-of-view, though, the order is
still retained by position on page so I'm not even sure where the item
option would be useful outside of the rare case where you've got
multiple _separate_ playlists on a single page.
(2) It would be great if there was a super simple minimal version of
the spec that people could actually write up by hand. While it was a
breeze to write code to programmatically markup a bunch tracks in
hAudio, I can't imagine ever actually writing any hAudio by hand, i.e.
if I was a regular blogger hand-writing links. For my part, I'd love
to see the hAudio-hTrack compatibility I accidentally stumbled across
in this process encouraged by basing a minimal version of the spec on
the work the Yahoo guys have already done. If you guys could figure
out a way to get the contributor name into that simple anchor markup
semantically and the YMP adopted it (and maybe the del.icio.us
playtagger as well), that would push a lot of adoption by the bloggers
who need the utility of actual playing tools as a motivator.
For reference, here's the relevant part of Grabb.it's track markup:
<a type="audio/mpeg" title="Heretics" href="http://grabb.it/tracks/013df2baebf6.mp3
" class="htrack download" rel="enclosure">Download MP3: Heretics -
Andrew Bird</a>
The rel="enclosure" bit is solely there for hAudio compatibility. the
"download" class is Grabb.it legacy that we'll eventually pull out now
that we can depend on "htrack" being on there. YMP uses the title
attribute in their player display, which makes me very tempted to put
the artist in there too like title="Heretics - Andrew Bird", but that
reduces the semantic coherence. If there was some other really easy
place to put the artist that YMP would pick up, I'd definitely do it.
And I'm pretty sure you'll never see an mp3 blogger using type="audio/
mpeg" which I technically don't need here since my mp3 urls always end
in .mp3, but doesn't hurt.
Finally, a minor note on a discussion you've been having:
-I definitely prefer 'title' to 'fn'. It's much more semantic and
perfectly easy to parse (from my point of view working on Mofo). ('fn'
strikes me as an example of how being a programmer can make us inured
to things having names which are arbitrary relative to the context
we're using them in, which is definitely not a common skill for
'normals').
Anyway, I hope that's helpful for you guys.
Thanks for you work on this format and thanks again to Martin for
helping me implement it!
yours,
Greg
---
http://grabb.it/users/greg
http://urbanhonking.com/ideasfordozens
http://atduskmusic.com
On Feb 19, 2008, at 4:25 PM, Manu Sporny wrote:
Gregory Borenstein wrote:
I'm one of the founders of Grabb.it, an online music player and
search
engine. With Martin's help, Grabb.it recently switched all of our
user
pages to use hAudio markup. These pages aggregate each user's
comments
and favorite songs. For example, here's mine:
http://grabb.it/users/greg
Fantastic work Greg - and Martin for doing the advocacy. Looked
through
the site - really cool idea and exactly the type of use case we were
thinking of when putting hAudio together.
Greg, if you have any constructive criticism on the hAudio format,
we'd
love to hear it. :)
-- manu
--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: RDFa Basics (video)
http://blog.digitalbazaar.com/2008/01/07/rdfa-basics
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
