Disambiguation [was RE: "uid" microformats? (was Re: [uf-discuss] ISBN mark-up)]

[Benjamin Carlyle]

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