[uf-new] hAudio ITEM/TRACK debate resolution
davidjanes at blogmatrix.com
Sat Oct 20 12:47:07 PDT 2007
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>
> 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.
The idea -- based on previous discussions, feedback, etc. -- was that
for hItem to be compatible with "hreview" (and others ) 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
This feels rightish to me, but I'm not wedded to it.
More information about the microformats-new