On 10/20/07, Brian Suda <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
