This is the current official definition of microformats from http://microformats.org/:
Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.
Many other definitions of microformats have been proposed, some of which I find more illuminating. This is the definition on the Microformats.org site:[307]
Microformats can be defined as: simple conventions for embedding semantic markup for a specific problem domain in human-readable (X)HTML/XML documents, Atom/RSS feeds, and “plain” XML that normalize existing content usage patterns using brief, descriptive class names often based on existing interoperable standards to enable decentralized development of resources, tools, and services.
Out of this definition, I would emphasize the following points:
Human-readable (X)HTML/XML documents, Atom/RSS feeds, and “plain” XML
Using brief, descriptive class names
It’s important to know about the intentional limitations built into microformats before criticizing them. From the list of things that microformats are not at http://microformats.org/
?about/, I will highlight a few. Microformats are not the following:
Infinitely extensible and open-ended
A panacea for all taxonomies, ontologies, and other such abstractions
Keep those limitations in mind when we compare microformats to specifications such as RDFa, which are aimed to be highly generalizable.
Because microformats involve both design philosophies and concrete formats (which you can use whether or not you subscribe to the microformats design philosophy), it’s easy to just ignore the philosophy. So if you want to just use the work of the microformats community, is this philosophy relevant? Probably—since there are a lot of design decisions that are hard to understand without knowing that philosophy.
Finally, with so many other ways to already get event data, what does having the microformat contribute to the mix? Well, there are at least two advantages:
For user-centered contexts, programs that have the (X)HTML source already—for instance, a web browser such as Firefox and its associated machinery (browser extensions, Greasemonkey scripts, and so on)—can reliably extract the event data and then present options to the user about what to do with that data. (The Operator Firefox add-on instantiates this idea.)
Spiders and other screen-scrapers can also extract the information reliably—without the usual heuristical guessing—to build aggregated databases of events across web pages. That’s what sites such as Technorati are doing.
In both cases, there is no need to make an extra call to the API to get this desired information about the event.