[uf-new] hAudio ITEM/TRACK debate resolution

Manu Sporny msporny at digitalbazaar.com
Sat Oct 20 11:16:08 PDT 2007


This e-mail is a proposed resolution to the hAudio ITEM/TRACK debate.
The list has seemed to have calmed down a bit, so I have gone back
through and attempted to address each post's concerns about using either
ITEM or TRACK. The proposed resolution is a mix of Martin, Scott, Andy,
Julian, Michael, David, Tantek, Brian, and Ben's input. It is a solution
that will hopefully work for everyone.

GOALS:

The primary goal is to create a mechanism for listing hAudio tracks
within hAudio albums.

The secondary goal is to create a mechanism that is expandable. We know
we might want to support classical music, opera, parts of podcasts,
top-lists and other forms of audio eventually, so the solution should
not prevent this from happening.

PROPOSAL:

1. HAUDIO can contain plain text to specify the FN property:
   <span class="haudio">Song Name</span>
2. HAUDIO parts are denoted by ITEM+HAUDIO:
   <span class="item haudio">Track Name</span>

EXAMPLES:

Album with two tracks, simple example:
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item haudio">Hokkaido Dream</span>
    <span class="item haudio">Tokyo Groove</span>
</span>

Album with two tracks, more detailed:
<span class="haudio">
   <span class="fn album">Best Before 1984</span>
   <span class="contributor">Crass</span>
   <span class="item haudio">
      <span class="fn">Hokkaido Dream</span>
      <abbr class="duration" title="PT3M24S">3:24</abbr>
   </span>
   <span class="item haudio">
      <span class="fn">Tokyo Groove</span>
      <abbr class="duration" title="PT4M46S">4:46</abbr>
   </span>
</span>

REASONING:

TRACK seems to be far too controversial of a name to use for the
property. There seem to be people on both sides of the debate and rather
than try and convince each other, let's re-frame the discussion to see
if we can agree on something else. The proposal above gives us the
following benefits:

 * Re-use of an existing Microformat property.
 * Not creating a new TRACK property (a Good Thing).
 * Pairing HAUDIO with ITEM solves the problem of ITEM being too generic
   and not specific (Andy and my primary problem with ITEM).
 * We are creating a number of short-hand markup approaches will allow
   publishers to write hAudio in a much easier way.
 * It enables marking up opera, classical music, and other singular
   recordings with movements, parts, sections, etc.
 * It allows the publisher to do infinite nesting (not that we have
   identified that as a need... but it also doesn't prevent it from
   happening, which is good).
 * We seem to have cracked the hSet/hBag/hContainer/item container
   problem.

These are the drawbacks that have been identified for the following
approach:

 * "ITEM HAUDIO" isn't as specific as TRACK.

If there isn't much push-back for this approach, we should probably
change the hAudio draft to reflect it and create an implementation in
Operator to test it.

Thoughts, comments, suggestions?

-- manu



More information about the microformats-new mailing list