[uf-new] hAudio ITEM/TRACK debate resolution

[Brian Suda]

On 10/20/07, David Janes <davidjanes at blogmatrix.com> wrote:
> 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

--- right, so in the examples, since there was only one "top-level" uF
the class="item haudio" would not need the extra "haudio" because we
know which we are talking about

> - if paired with an appropriate semantic class -- e.g. "haudio" or
> "track" -- then the hItem refers to that particular sub-element of the
> uF

--- i don't perticularly like "sectioning off" of microformated data.
Firstly, we are venturing into theoretical territory with "what if an
haudio was in an hreview", but this is a solvable problem with the
tools and rules we already have.

<div class="hreview">
<span class="haudio">
    <span class="fn album">Best Before 1984</span>
    <span class="contributor">Crass</span>
    <span class="item">
        <span class="fn">Hokkaido Dream</span>
    </span>
   <span class="item">
        <span class="fn">Tokyo Groove</span>
    </span>
</span>
</div>

In this case the FN of the hReview would be THE FIRST fn it finds in
an item object, so it would be Hokkaido Dream. To fix this, simply add
am "item" property into the <span class="haudio">.

<div class="hreview">
<span class="haudio">
    <span class="fn">Best Before 1984</span>
    ...

Then the first FN that is found inside an ITEM inside an HREVIEW is
now "Best Before 1984" the other items are ignored in the context of
hreview but NOT for haudio. It solves both problems without extra
mark-up.

As for hItem, if it went by the same "first only" rules, then it would
find 3 items, with 3 corresponding FNs without the need for any
sectioning off of data.

I think that solves the issues nicely. The "type casing" of what an
item is optional. We do it with hResume, and somewhat with hCard's
ADR. The ADR should be an hCard, just like the class="contributor"
SHOULD be an hCard, but isn't a MUST. We should examine this more on a
case-by-case basis if issues arrise rather than protect against
something that might not even exist.

-brian

-- 
brian suda
http://suda.co.uk