[uf-new] hAudio proposal: ITEM/TRACK

[Martin McEvoy]

On Sun, 2007-10-14 at 16:01 -0400, Manu Sporny wrote:
> The problem:
> 
> We need some sort of "container" to hold track/song information in an
> hAudio album. The contents of this "container" will be another hAudio
> chunk or text (which will be the FN of an hAudio object).
> 
> There are two proposals that are on the table right now. The end result
> and semantics for hAudio are the same, the only thing that we are
> discussing is the name of that "container".
> 
> TRACK or ITEM
> 
> Using TRACK means creating a new Microformat property that, while
> specific, is not re-using ITEM. There is also contention over whether
> this accurately describes a part of an album.
> 
> Using ITEM means that we will be changing the current definition of ITEM:
> 
> -----------------------------------------------------------------------
> 
> "item - hReview - The item that the object exists for. For example, a
> review about Coca-Cola would list "Coca-Cola" as the item."[1]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name, except for an event item
> which MUST have the "summary" property inside the respective hCalendar
> "vevent") of the item (an hReview describes only one item), SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) MUST be encapsulated
> in an hCard. For items of type event, the item info SHOULD be
> encapsulated in an hCalendar "vevent". Non-URL unique item IDs (e.g.
> ISBNs, UPCs) MAY be represented as a URN ("url") for the item.
> Encapsulated microformats (e.g. hCard and hCalendar events for now) may
> be set on the item itself (e.g. class="item vcard"). However, when using
> item info subproperties ("fn", "url", "photo"), they MUST be nested
> inside the item element."[2]
> 
> "item info:: This required field MUST have at a minimum the name ("fn" -
> the formatted text corresponding to the name) of the item , SHOULD
> provide at least one URI ("url") for the item, and MAY provide at least
> one URL to a photo or depiction ("photo") of the item. For items of type
> person or business, the item info (fn, url, photo) SHOULD be
> encapsulated in an hCard. Unique item IDs (e.g. ISBNs, UPCs) MAY be
> represented as a URN ("url") for the item."[3]
> 
> -----------------------------------------------------------------------
> 
> However, it seems that there is support from a number of people to
> re-use ITEM because it achieves two things (moves hAudio forward AND
> simultaneously creates a generic "bag/hset/container" concept for
> Microformats... something that we've been attempting to do for over a year.
> 
> We don't want to break backwards compatability, so we have to work with
> the current definitions of item for hReview and hListing by defining
> ITEM as the following, which can be used across all Microformats:
> 
> -----------------------------------------------------------------------
> 
> ITEM - A generic method that Microformats use for unordered containment
> of other Microformat properties or objects. This property MUST have, at
> a minimum, the name of the item. The name of the item can be specified
> using either:
> 
>   a) plain-text, if the property contains only the name of the item.
>   b) "fn", if the property contains multiple Microformat properties.
> 
> ITEM MAY contain other properties/Microformats, but anything other than
> FN must be defined by the Microformat that is using ITEM.
> 
> -----------------------------------------------------------------------
> 
> The above definition doesn't require hReview or hListing to change at
> all. It also means that we can use it like so in hAudio:
> 
> Single track, with known album (same as putting text in the ‘album’
> field of an ID3 tag):
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Single track, album unknown:
> <span class="haudio">
>     <span class="fn">Nagasaki Nightmare</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
> </span>
> 
> Album with a couple of tracks, simple example:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item">Nagasaki Nightmare</span>
>     <span class="item">Hokkaido Dream</span>
>     <span class="item">Tokyo Groove</span>
> </span>
> 
> Album with a couple of tracks, more detailed:
> <span class="haudio">
>     <span class="fn album">Best Before 1984</span>
>     <span class="contributor">Crass</span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> – <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> – <abbr class="duration" title="P268T">4:46</abbr></span>
>     <span class="item haudio"><span class="fn">Nagasaki Nightmare</span>
> – <abbr class="duration" title="P268T">4:46</abbr></span>
> </span>
> 
> -- manu
> 
> PS: Andy, Martin - I'm just as frustrated with this approach as I'm sure
> both of you are, especially since it was deemed that we couldn't change
> TITLE from hCard... but now we're changing the meaning, quite blatantly,
> for ITEM.

Hi Manu very thorough summary can you clarify one thing for me
How are we quite blatantly changing the meaning for ITEM?

[1] http://microformats.org/wiki/item

...

Thanks

Martin
> 
> [1] http://microformats.org/wiki/existing-classes
> [2] http://microformats.org/wiki/hreview#Field_details
> [3] http://microformats.org/wiki/hlisting#Item_Metadata
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new