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@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
--
Martin McEvoy
http://weborganics.co.uk/
_______________________________________________
microformats-new mailing list
microformats-new@microformats.org
http://microformats.org/mailman/listinfo/microformats-new
