I think there is a reasonable cause for concern that microformats do not use URIs for the extensibility points used in HTML. The issue is that class attributes in html elements such as span, div contain bare names, such as hreview, fn, title, etc.
Tantek argues in a wiki entry called misconceptions that the microformats do use URI based extensibility because microformats make use of the profile attribute in the <head> element to reference one or more profiles. The wiki does mention needing profile URIs at http://microformats.org/wiki/profile-uris.
However, I've found the real world to be quite different. I tried generation programs such as hreviewCreator and they did not produce profile attributes. I tried parsing programs like operator, and it parsed the microformats fine without profile.
I also searched for "profile" in the microformats wiki site, and it is almost never mentioned. It is never mentioned in hReview as such, including the XMDP Profile. I looked through hCard and the use of profile is only mentioned once as a footnote in the hcard wiki page, never on the examples page, never on the FAQ. In supreme irony, the hcard examples page itself does not use the head profile attribute. It is mentioned very strongly in the hcard-profile page. But the hCard Builder doesn't create the profile attribute. There's about 64 mentions of "head profile=" in microformats.org according to google, but most of those are 2005 archives of messages and little discussion since then.
It appears to me that for all intents and purposes, the microformats are not using URI based extensibility because the profile attribute is hardly ever used. One of the main reasons I think that the profile attribute is hardly ever used is because it is "separate" in the document from the microformatted text. When somebody creates a microformat using a tool and then pastes it into the HTML, they almost always don't update the head element. Not that the ones I used mentioned this anyways.
Further, I think many of the parsing tools, like operator, are ok with ignoring the missing profile attribute and doing what they can. This promotes not using the profile attribute, similar to the missing doctype problem that Tantek talks about. It would be great if more "view source" kinds of applications had a "display correct source" option, as TimBL regularly suggests.
There is a message from Harry Halpin on the www-tag list that does a good job of expanding on the issues around profile attributes in general, where HTML WG may be going with profile, alternatives, and how GRDDL uses profiles.
One thing he mentions, which I think is absolutely at the core of this, is who owns the class attribute values in the html namespace. As he says
One possible "work-around" for profile URIs for microformats would be to let the "profile URI" of microformats that do not use a profile URI be the HTML namespace [2],and so ground them in the HTML URI space itself. This is politically tricky since so many groups have their fingers in that namespace and the process for altering it is a bit unclear to me.
Exactly. I think there is huge irony of moving to unprofiled attributes being in the html namespace. The irony is that the solution to the problem of decentralized evolution is to centralize the evolution! Now it does make sense that HTML "owns" it's attributes and attribute values, and anybody that doesn't use a profile is "squatting". Or maybe it's already far too late.
One possible "work-around" for profile URIs for microformats would be to let the "profile URI" of microformats that do not use a profile URI be the HTML namespace [2],and so ground them in the HTML URI space itself. This is politically tricky since so many groups have their fingers in that namespace and the process for altering it is a bit unclear to me.
I dont think groups should have a finger in the namespace. There are lots of other way to profile URIs
wiki learning