[uf-new] hAudio 1.0 Draft Release

[Martin McEvoy]

Hello Manu
Manu Sporny wrote:
> Martin McEvoy wrote:
>   
>> This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema
>>     
>
> It's good to see this moving forward as I haven't had any time to work
> on hAudio over the past couple of months. :)
>
>   
;-)
>> Removed properties that are 70% or less of discovered elements
>>
>> category
>> description
>> sample
>> payment
>> price
>> item
>>     
>
> A couple of issues with the approach that is being taken:
>
> 1. These are very large, substantiative changes. There are currently
>    no issues logged against any one of these attributes[1]. Shouldn't
>    there be an issue logged against each one of these removals so that
>    we can discuss the removal as per the uF Process?
>   
They were logged as issues see: 
http://microformats.org/wiki?title=haudio-issues&diff=prev&oldid=29669

But I Removed the issues because these are not issues they are 
properties that should not have been included at all

> 2. Why remove all properties below 70% coverage? I thought we were
>    attempting to solve the problem for roughly 80% of the sites out
>    there? This proposal has us solving the problem for roughly 30%
>    of the sites out there. 
Manu, haudio can not be all inclusive, Including properties that are 
blow  70% (and I am being fair here) is somewhat akin to "boiling the 
ocean", and confuse what we are actually trying to archive which is a 
simple microformat for music downloads, NOT to be confused with music 
download sites which are a different thing altogether as most of which 
do not relate to the final file location at all and could easily be 
marked up using hListing
> Why are we suddenly ignoring 50% of our
>    use cases?
>   
We are not ignoring them there simply is not enough evidence top support 
these extra properties at this time.
> 3. I'm afraid that removing these properties will delay hAudio from
>    reaching draft stage for much longer. Each removal requires a
>    discussion, since we have had very long discussions to get each one
>    of these elements into hAudio.
>   

The point is they are not part of this discussion, simplifying hAudio is 
the easiest option
> There are currently no issues on the hAudio issues page for all of these
> removals. The only issue that we have to resolve right now to get hAudio
> to draft stage is this one:
>
> http://microformats.org/wiki/haudio-issues#D5:_2008-01-10__there_is_no_way_of_linking_to_an_interim_page
>
> Now we're talking about adding roughly 8 new issues that are going to be
> highly contentious to the debate. Why don't we just address hAudio Issue
> D5 and proceed to Draft?
>   

Because as haudio stands at the moment, It STILL does not answer the 
problem of a music download, only the problem of music download sites, 
which more concerns itself with selling audio which can as I said 
earlier can quite amicably be resolved using hListing.

Also haudio Is far to complex for authors to pick up and use it needs to 
be simplified, the only way I have found to do this reliably is to look 
at how haudio is currently implemented
> Issue D5 is your issue Martin - if you dropped it, we could proceed to
> draft immediately. Or we could find enough examples to support it, adopt
> it and proceed to Draft. Your proposal has us delaying hAudio for
> another 6-8 months (based on how long it's taken us to get through the
> five issues logged against hAudio in the first place).
>   

I will place all the removals on the haudio issues page, I thought I 
would like to pass it all by you all first
>   
>> Recommended addition
>>
>> length(size)
>>     
>
> While I agree that this would be a useful addition, we currently don't
> have any examples to back up the addition of this attribute to hAudio.
> We'd have to provide enough examples - even by your requirements
> outlined above, we'd have to prove that 70% of the sites out there
> publish this information (which they don't).
>   
I beg to differ all the examples that relate to the final location of a 
download itself,  Mainly in the Podcasting examples and Individual 
publishers of music do have a length(size) property this is not 
immediatly evident on the page but is evident when the audio is being 
downloaded
>   
>> Publishing Recommendations
>>
>> hAtom[3]  or XOXO[4] should be used for grouping audio
>>     
>
> We've had very long discussions on using item for grouping hAudio and it
> has been shown to work quite well. Why are we suddenly changing this?
>
>   
Because how to group haudio has never been an Issue it only became an 
issue when you merged halbum into haudio, you didn't run that by the 
list when you published the halbum pages why was that?, I aired my 
concerns about this off list  saying tat any discussion around a  halbum 
microformat should be merged into the haudio discussion, I certainly did 
not mean that we should change the topic of the audio-download 
discussion to include collections of audio it is too complex and outside 
of the scope of hAudio because not answering the problem of grouping 
enables a simpler cleaner format that can be grouped in any way a 
publisher needs.
>   
>> I hope to make the above recommendations Final  and make the above
>> changes within the next week or so.
>>     
>
> I certainly hope that we won't change hAudio so drastically over the
> next week, especially since there are no logged issues against any of
> these ideas.
>   
Not drastic at all Manu what is drastic is how hAudio stands at the moment.


Best wishes

Martin McEvoy
> -- manu
>
> [1] http://microformats.org/wiki/haudio-issues
>
> _______________________________________________
> microformats-new mailing list
> microformats-new at microformats.org
> http://microformats.org/mailman/listinfo/microformats-new
>   
-- 
Martin McEvoy

http://weborganics.co.uk/