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

Martin McEvoy martin at weborganics.co.uk
Sun Oct 14 11:12:09 PDT 2007

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


Field details Track

A container for another hAudio item. Used in conjunction with

      * 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

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

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"



More information about the microformats-new mailing list