[uf-new] item property (was: hAudio: audio-title/album-title vs. recording/album)

[Andy Mabbett]

In message <1192385529.9987.31.camel at localhost.localdomain>, Martin
McEvoy <martin at weborganics.co.uk> writes

>> >> [1] http://microformats.org/wiki/item
>>
>> In which, David Janes said:
>>
>>         hItem should [...] not be a general purpose dumping ground for
>>         attributes

>Item suits our type purpose definition

I'm not clear whether you're just expressing an opinion; or speaking on
behalf of some undeclared group, when you use "our".

The definition of "item" on:

        <http://microformats.org/wiki/existing-classes>

does NOT match the use proposed for item in hAudio.


>I also think that if we go ahead and use TRACK then we WILL be causing
>huge problems when it comes to "future" microformats as TRACK has more
>than one meaning not many of which match out Definition

>TRACK has many meaning and no single meaning in the real world

As do "class", "contact", "experience", "key", "label", "latitude",
"note", "profile", "region", "sound" and many other class names already
used in microformats.

I don't see the relevance of track's other meanings, to this issue.


>How would you feel when it comes to marking up hRacetrack, or
>hTraintrack and you find that hAudio has already defined TRACK to mean
>
>"A container for another hAudio item"

Perfectly relaxed; unless you intended to wrap hRacetrack or hTraintrack
(!) in hAudio.

Are you suggesting we should use "album-track" instead of just "rack".

-- 
Andy Mabbett