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

[Martin McEvoy]

On Sun, 2007-10-14 at 17:42 +0100, Andy Mabbett wrote:
> In message <1192374509.9987.17.camel at localhost.localdomain>, Martin
> McEvoy <martin at weborganics.co.uk> writes
> 
> >On Sun, 2007-10-14 at 08:50 -0500, David Janes wrote:
> 
> >> Note that a did a moderate amount of work on this last year [1]
> 
> >yes I did notice that you have done a lot of work already to support an
> >item design pattern or submicroformat
> 
> >> [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

>From the audio-info-proposal

http://microformats.org/wiki/audio-info-proposal#Track

Field details Track

A container for another hAudio item. Used in conjunction with
album-title. 

      * The element is identified by the class name track.
      * hAudio MAY have one or more tracks, but MUST have album-title
        defined. If album-title is not defined, track cannot be defined.
      * The element MUST be processed opaquely. No sub-elements should
        be read from any hAudio contained in a track element.
      * The contents of the element MAY be plain-text or marked up using
        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

http://www.answers.com/track&r=67

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

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"

Thanks

Martin