Brian, you have made some very valid points, I'm not disputing most of what you have said. I feel that this discussion is getting a bit off-track.
>From your various e-mails, you seem to be making the following points (I'm paraphrasing, there are nuances, but I'm attempting to summarize): 1. We should minimize duplication of work between what we do here and other standards bodies. 2. Big standards bodies (like W3C, IETF, etc.) have corporate sponsors that may not have the publisher's best interests in mind. 3. The Microformats community is all-inclusive - "The Process", logic, reasoning and open debate should prevail. Most standards bodies have a great deal of red tape and preferential treatment for paying members. 4. Microformats are not a "throw everything at the wall and see what sticks" methodology. It is a very careful process that provides a minimum set of markup that solves 80% of publisher issues out there. Personally, I agree with all of these statements. It is a very good thing that the Microformats community follows them and holds them at its core. We are not talking about changing any of that. A very high level view of the Microformats creation process could be proposed as thus: 1. See if you have a problem. 2. Gather examples of the problem you are attempting to solve. 3. Analyze examples. 4. If analysis deems necessary, create a draft Microformat. 5. Brainstorm and argue about names, usage - document via wiki. 6. Implement the Microformat, get feedback. 7. Create Microformat specification. 8. Evangelize the Microformat (especially, in other standards bodies). hAudio is at step 5 right now. Keep in mind that it only solves 80% of the publishing problems out there... which means that there are the 20% that are still left without a solution and will seek that solution. Why should we not weigh in with the people that are taking the time to solve the other 20% of the problem? We have a great deal of knowledge in this community and can help solve the problem completely by giving other communities a very strong base to start from. If they don't listen to us, we are no worse off than we are by doing nothing. If they do listen to us, we can stop a plethora of useless semantic formats that are not needed. Another way to look at it is that we can talk other communities out of creating a ton of different standards by proposing that they use the Microformats semantic vocabulary as a starting point. If it solves their problem, there is no need to create yet-another-semantic-format. My arguments have nothing to do with changing the Microformats process - they have to do with interacting with other communities. We can prevent duplication of work in other locations by taking part in the discussion. Or, we can do nothing and let the duplication of work knowingly occur. I'm not claiming to have all of the answers. There certainly could be down-sides to what is being proposed. However, those are not as bad as not working with other communities. I assert that, in general, collaborating with other communities will strengthen the acceptance of Microformats. We plan to work with the RDFa group to see if they can use hAudio. It is also an attempt to stop a dearth of semantic formats that do the same exact thing. We're trying to prevent what we fear is going to happen with RDFa. -- manu _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
