On Sun, 2007-10-14 at 17:42 +0100, Andy Mabbett wrote: > In message <[EMAIL PROTECTED]>, Martin > McEvoy <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-new mailing list microformats-new@microformats.org http://microformats.org/mailman/listinfo/microformats-new
