On Wed, 2006-04-26 at 11:53 -0700, Joe Andrieu wrote: > Tantek wrote: > >> Who is the registrar? > >Currently we have profile URLs at http://gmpg.org/ and http://w3.org/ > Scott wrote: > >> Alternatively, who is to say which version of hCoupon is valid? > >Mark Pilgrim. Rather, Mark is working on a validator, based on the > specs at microformats.org. > It appears to me that there is no registrar. Whether or not we need one is > a different issue, but I'd like to be clear in my understanding.
It is not clear to me at this time that microformats need profiles. hcard seems to have several profiles: http://microformats.org/wiki/hcard-profile http://www.w3.org/2006/03/hcard hcalendar seems to have none. Has this harmed adoption or made tooling more difficult? I don't think so, at least not so far. Microformat tools and authors currently depend upon popular terms like "vcard" and "vcalendar" to positively identify their particular microformat within a particular html document. Different versions of some microformats exist in the wild, but we consider it a requirement that early adopters eventually update their sites to the released specification and that released specifications are (almost certainly) backwards-compatible through subsequent revisions. Microformat terms act like profiles in identifying how to process the content, so what else would using a profile add: 1) The ability to skip parsing of a html document (or parts thereof) becase we don't see the profile elements we recognise. 2) To provide additional disambiguation: To tell a parser which vcard specification or version to use. 3) To identify the fact that some microformats are in use, ie use "http://microformats.org/" instead of a profile for a specific microformat. I think that (1) is based on a false premise. You have to at least start parsing the html document in order to know which profiles are used. Chances are that profiles will be frequently missing or incorrect given the current tooling situation. I think parsers will look for microformats they know about no matter what the profiles attribute says. (2) and (3) also seem like a bad ideas. They would be technical measures to allow the established microformat community base to splinter. While we all live within one namespace we are force to interact with each other to resolve conflict. Outside of that space confrontation is avoided and we end up with "mymicroformats:vcard" and "yourmicroformats:vcard" class names. Publishers would be forced to choose between the two. I have a write-up of some related thoughts on xml namespaces at [1]. They were inspired by an article by Mark Nottingham [2]. At the moment, the html class name world is divided into the microformat controlled vocubulary and the general population's folksonomy. I think this tragectory is working so far. I don't see a need to change it for the moment. It may still be useful to maintain a registry that helps people avoid terms already in use. We have [3] as the current state of that. Comments? Benjamin. [1] http://soundadvice.id.au/blog/2006/04/11#namespaces [2] http://www.mnot.net/blog/2006/04/07/extensibility [3] http://microformats.org/wiki/existing-classes _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss