[uf-new] hAudio 1.0 Draft Release

[Martin McEvoy]

Hello Toby

Toby A Inkster wrote:
> 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>
Yes I agree it is more to do with enclosures in general, Atom, and RSS2 
use length for this, pending other ways of doing this I think the best 
option at the moment is keep it simple.
>
> 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.
>
do you not think by looking at all the examples you are looking at the 
data surrounding the audio not the audio download itself?,  with the 
acception of service publishing of music( 59% of the examples show this) 
category or tag is not used at all.
> 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.
hAudio can Not be compared to haudio the process of creation was not the 
same as hAudio. hCard is a n=>n representation of the vCard format, 
hAudio is based on usage and publishing patterns.

> The 80/20 principle is not meant to be applied this way.

In the end Yes it is, if a property doesn't come within 80% of popular 
publishing patterns It doesn't belong in the format that is why the 
microformats process is fair.
>
> 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. 
No not at all If you are publishing a review of an audio the yes use 
hreview, If you are publishing a podcast then use hAtom with haudio 
enclosures, if you are selling audio then use hListing, it all seems 
like a no brainer to me because in the end you will have a no nonsense 
audio format that can be easily embedded in any existing or future 
microformat.
> 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.
Indeed it is useful but can you cite any real life examples of this, 
where factual information can be read about an individual peice of 
audio?, I am not saying they dont exist, I would just like to establish 
the exact source of your problem.
>
> 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.

Yes a lot of the service publishing of music examples use tables, but an 
equal amount use lists and as you say free form 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>

No it wouldn't but then again I have never seen markup like the above 
before, is it a review, a listing a blog post?  I cant solve 
hypothetical issues. Don't get me Wrong Toby I think Item is amazingly 
useful In just think it confuses the purpose of a music -download 
microformat, Grouping, Collections , is not an issue haudio has to 
solve, I think on the whole should be moved to another discussion.
>
> 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.
Quite the opposite really Toby Microformats ARE constrained vocabularies
>
>
> 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.
Not new something that caused problems earlier in the discussion type is 
enclosure type eg:

<a rel="enclosure" href="my-foo-file" type="application/x-foo">Foo</a>

I would just like to make type more explicit  in the hAudio format itself.
>
> 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.
>
Hmm you know I dont see "album" as a property at all on the 
brainstorming page

http://microformats.org/wiki/audio-info-brainstorming

but I can accept that this property exists in the examples pages, making 
album a required property seems extremely restrictive to me I don't 
understand the logic behind it at all.

Thanks

-- 
Martin McEvoy

http://weborganics.co.uk/