[uf-new] hAudio 1.0 Draft Release

[Toby A Inkster]

Firstly, I'd like to say that the proposal for a way of marking up  
file sizes is a good idea. Perhaps it should not be part of hAudio in  
particular though, but adopted as part of the wider rel-enclosure/ 
downloads effort. e.g. give class="length" a meaning when found  
within rel-enclosure:

	<a rel="enclosure" href="some-file"
	>Some File (<span class="length">12345</span> bytes)</a>

However, I strongly object to the removal of terms from hAudio -  
category, description and item in particular. My reasons are as follows:

1. I think this is a misapplication of the 80/20 principle. The idea  
of the principle is not to discard any properties which are used less  
than 80% of the time, but rather to create a format which covers 80%  
of use cases. Looking through the audio examples list on the wiki  
shows that at least half of them include, say, some form of  
categorisation - so if we leave out "category", then at least half of  
them can't be fully described using hAudio, so we haven't created a  
format which covers 80% of use cases.

If the 80/20 principle worked the way Martin is applying it here,  
hCard would only include 3 properties: "fn", "url" and "email" (and  
the latter two would be at risk). 80% of the time a person is  
mentioned on the web, telephone numbers are not provided (e.g. my  
email signature, Martin's email signature), so "tel" would go. 80% of  
the time a person is mentioned on the web, addresses aren't provided,  
so "adr" would go to. Et cetera. The 80/20 principle is not meant to  
be applied this way.

2. Regarding "category" in particular, it should be noted that a form  
of categorisation (either class="category" or rel-tag) is adopted by  
almost all compound microformats. It provides a valuable  
extensibility mechanism to encompass bits of data which the designers  
of the microformat didn't take into account. e.g. tagging hCards as  
"Male" or "Female" is the officially recommended workaround for the  
lack of a "gender" property. A large number of the examples on the  
audio-info-examples wiki pages include the record label, the album  
genre and the audio medium (e.g. CD, download, LP, cassette, etc).  
All of those could be marked up using a categorisation mechanism.

3. Regarding "description", you suggest that hReview should be used  
instead. When a review of the audio item is being offered, then I  
agree that this is the best way of doing it. However, "description"  
has other purposes - it may contain factual information which is not  
a review. e.g. it could mention the location where some audio was  
recorded. In that sense, it also provides another extensibility  
mechanism for marking up information about a recording which is  
otherwise beyond the scope of hAudio.

4. Regarding "item", you suggest XOXO as a replacement. XOXO relies  
on <ul> and <ol> elements. Audio info in the wild often marks up  
items using tables, or refers to them in free text. The following for  
example, wouldn't work well with XOXO:

	<p class="haudio">
	  The best known songs from
	  <span class="contributor vcard">
	    <span class="fn org">The Beatles</span>'
	  </span>
	  <span class="album">white album</span>
	  are probably
	  <span class="item">
	    <i class="fn">Back in the USSR</i>,
	  </span>
	  <span class="item">
	    <i class="fn">While My Guitar Gently Weeps</i>
	  </span>
	  and
	  <span class="item">
	    <i class="fn">Revolution 9</i>,
	  </span>
	  but it contains many lesser known classics.
	</p>

This sort of in-prose markup seems to be often forgotten about in the  
development of microformats, but for microformats to be useful in  
such situations, it's important to not constrain the choice of  
elements used too much.

On your list of "stuff we're keeping" you seem to have slipped in a  
new property "type" without explanation of what is means, or  
justification for its existence.

Lastly, on your list of "stuff we're keeping", you say that "fn" is a  
required property. This represents a departure from hAudio 0.9, where  
albums are marked up using "album" instead. The presence or absence  
of these two properties is used to differentiate between albums,  
tracks on albums, and standalone tracks, which I think is a useful  
distinction.

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>