Manu Sporny wrote:
Martin McEvoy wrote:
In Microformats this means that if a propery is used more than 80% of
the time then it should be included in the format,
We'll call this Statement A. If we were to hold this true, then we would
be left with these properties for hAudio. We would
On [Oct 29], at [ Oct 29] 7:39 , Martin McEvoy wrote:
The above information has been the crux of my issues with the audio-
info process, because we haven't YET created a microformat for Music
Downloads.
The Proposal to create a Microformat for Music Downloads (If any one
remembers) was
Martin McEvoy wrote:
In Microformats this means that if a propery is used more than 80% of
the time then it should be included in the format, this will result in
the top 20% of all discovered properties making their way into the final
Microformat.
You continue to contradict yourself, which is
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
Hello
This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema
Properties that are 70% or over of discovered elements determined by the
audio-info examples[2]
haudio (required)
fn (required)
contributor
album
enclosure
type
published
duration
position
photo
Removed properties
To: For discussion of new microformats.microformats-new@microformats.org
Subject: Re: [uf-new] hAudio 1.0 Draft Release
Hello Scott.
Scott Reynen wrote:
On [Oct 15], at [ Oct 15] 7:06 , Martin McEvoy wrote:
This email is to announce the hAudio[1] 1.0 Final Draft proposed Schema
[1] http
Tantek Celik wrote:
Additionally: in general I agree with the methodology of
simplifying/reducing the schema and property set -
hence the start as simple as possible principle as
documented:
In general, I agree with simplifying/reducing the schema and property
set as long as it still
Manu Sporny wrote:
Martin McEvoy wrote:
Toby Inkster wrote:
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
Answering several messages in one...
Martin McEvoy wrote:
In Microformats this means that if a propery is used more than 80% of
the time then it should be included in the format, this will result in
the top 20% of all discovered properties making their way into the
final
Microformat.
Sigh!
Toby A Inkster wrote:
Answering several messages in one...
Martin McEvoy wrote:
In Microformats this means that if a propery is used more than 80% of
the time then it should be included in the format, this will result in
the top 20% of all discovered properties making their way into
Toby A Inkster wrote:
I had to look at the early implementers of haudio
and see how they were using Item, No One currently is using Item
The following use item...
For the Record Item Is a useful property in haudio, It is just defined
incorrectly in the proposal
In haudio Item is not
On [Oct 15], Martin McEvoy wrote:
Sigh!
Indeed.
The content type should certainly be made explicit when known, but
making it a class name is a mistake - the type attribute should be
used as above. Making it into a class takes it away from the link,
so you end up with stuff like this,
Scott Reynen wrote:
On [Oct 15], at [ Oct 15] 2:58 , Martin McEvoy wrote:
None of the proposed removals are issues, I am simply applying the
80/20 rule to the existing schema using the Microformats Process
If the 80/20 principle (not rule) hasn't been applied appropriately,
that's an issue.
Martin McEvoy wrote:
http://microformats.org/wiki/haudio#Parser_Processing_Notes
Parser Processing Notes
* It is important to understand that ITEM is an opaque element. When
processing the ITEM element, none of the properties of the child
hAudio should be pulled into the
14 matches
Mail list logo
