> Mike Schinkel wrote: > > Ryan Cannon wrote: > > If the community is slow to develop a format that makes > > sense, we often encourage authors to develop their own > > systems, which then can inform how a format will function in > > the wild. This is where documentation and the oft-belabored > > "process" becomes powerful. Although it can be annoying for > > early-adopters and people who need solutions now, it creates > > strong formats once the issues are solidified. > > Arrgghhh! (he says, frustrated that people address the > tangent to his issue, but don't/won't address his actual issue!) > > So I repeat: How then can we achieve a disambiguation > conventions to keep official Microformats from conflicting > with "proto- Microformats?"
Mike, Microformats has no mechanism in place to disambiguate, either amongst its own uFs or between its own and other "non-official" microformats. Tantek wrote: > A "microformat" is such because it is a use of semantic class > names, etc. that IN PARTICULAR: > > 1. Are designed according to microformat principles [1] > > 2. Follow the microformats process [2] > > [1] > http://microformats.org/wiki/microformats#the_microformats_principles > > [2] http://microformats.org/wiki/process Although the process says to use the microformats wiki and mailing list, there is no "official" blessing as both of these media are either unmoderated or "community" moderated. Any user could make recommendations and edits. A team of antagonistic users could hijack it completely. There really is never an "official" version of any given microformat, although there have been statements that eventually their will be when shepharded through a standards body. The only real authority is the autocratic role played by Ryan and Tantek. For example, since it was initially stabilized hCard has been changed to include "place" in its semantics, yet we have no way to let parsers know that the "new" hCards may not be people, companies, or organizations, but instead may also be places. vCards were for /contactable/ entities. hCards changed the semantics to include "locatable" things because the address capability of existing hCards made that convenient. Yet, there is no versioning to disambiguate between these two. That means that once a standards body blesses any particular microformat, it will be locked in stone. I for one think hPlace (or something) should be a separate uF, based on the location-related fields in hCard. Similarly, there is no mechanism to distinguish class names in one hcard from names in another, so we are forced to make sure that the entire namespace is flat and hopefully unique enough from random semantic HTML in the wild. If it looks like a duck and quacks like a duck, you really can't tell if it is a duck, but the parsers will try to treat it like a duck anyhow, even when it is simply semantic HTML that happens to have the same class names as a microformat. The initial concept, as I understand it, was that divergent, namespace-enabled variants are bad. That instead, a community-forged single namespace based on consensus is better. I agree with the intent of the latter. It is good to have a shared tongue. However, I think that goal is compatible with the existence of namespaces (or other disambiguation). Just as having an international language of commerce and science is good (English serves this purpose today), it is also entirely compatible with a world where people are allowed to speak other languages, especially when knowing which language they are using helps you clarify their meaning. I, for one, think we need a mechanism to disambiguate, but I didn't have much success with my early arguments. Apparently I hit a lot of hot-buttons and got shouted down (some of my suggestions were somewhat tangential to this particular point and probably deserved getting shouted down). The idea of disambiguatable namespaces stirs up exhortations against a "Babel"-like profusion of uFs, which apparently would be the end of the world and somehow inherently prevent the forging of the consensus uF namespace. I don't buy that argument, but it is the one that has held sway here since the creation of microformats. That's ok. Microformats are still cool. I just don't think they scale well, which is apparently by design. -j -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
