[uf-new] hAudio ITEM/TRACK debate resolution

[David Janes]

On 10/20/07, Brian Suda <brian.suda at gmail.com> wrote:

> > These are the drawbacks that have been identified for the following
> > approach:
> >
> >  * "ITEM HAUDIO" isn't as specific as TRACK.
>
> --- this is a good thing, it is just an ITEM. We can reuse all the
> semantics of hReview. For things like iTunes "buy this album and get a
> video too" now you can still use ITEM to represent a nested VIDEO or
> PDF or other formats, not just AUDIO.  Using the class="type" you
> could specific what it is, track, video, pdf, etc. If there is no TYPE
> it is assumed to be an audio track. I don't think we need to make the
> connection of "item haudio" to "cast" the item as an audio element.
>
> So if you want to talk about JUST a track you can do this:
> <span class="haudio">
>      <span class="item">
>          <span class="fn">Hokkaido Dream</span>
>      </span>
> </span>
>
> it might be slightly more verbose that you want, but we can always
> discuss optimization later once we have real data to work with. Lets
> not throw the baby out with the bathwater. First get a working format,
> then iterate for optimizations.
>

Hi Brian,

The idea -- based on previous discussions, feedback, etc. -- was that
for hItem to be compatible with "hreview" (and others [1]) it would
defined as follows:
- if not paired with an appropriate semantic class, the hItem refers
to the "top level" uF -- this is how hReview and hListing use it
- if paired with an appropriate semantic class -- e.g. "haudio" or
"track" -- then the hItem refers to that particular sub-element of the
uF

This feels rightish to me, but I'm not wedded to it.

Regards, etc...
David

[1] http://microformats.org/wiki/item-formats#hListing
-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://blogmatrix.blogmatrix.com