Seriously, I like microdata, I think it's useful, but this kind of utopian, far-away 'we should use this because it might be better in the future' never got us anywhere. That is the lesson we should learn from XHTML2, not 'adding more attributes is cool'.
Standardized metadata can serve as a platform for other services, not just functionality in a browser. And the common sentiment that "we should use this because it might be better in the future" is a hurdle most standards go through at some point.
On the other hand, you might argue that it's simply a coordination problem (http://en.wikipedia.org/wiki/Coordination_game).
In any case, it's somewhat shortsighted to look for immediate, personal benefits. Of course you need to look at the payoffs for implementing a spec, but I think it's wrong not to take longer-term possibilities into account.
Someday, it would be nice if every single street address on the web was marked up in such a way that just from looking at the markup, a computer can unambiguously figure out the location you're looking for. Or a way for browsers to unambiguously know that something is a phone number and not a zip code (Android does a horrible job of this. Try texting your current location from the maps app.)
I guess, the semantic web remains a dream, but that's no reason to avoid adding semantic data, especially if you want computers to interact with your data directly.
<a href="tel:+44-555-5555">my phone number </a>
Gordon Luk, the lead engineer, wrote an excellent post describing his frustrations with microformats:
[...] my experience with being a microformat publisher
has shown that things are exponentially more complex
than they let on in the “sales pitch.”
HTML5 Microdata seems slightly more rigorous and abstract, but still, commingling presentational HTML with an informal data API is just asking for trouble.
Also, I'm waiting for a usable "Receipt" microdata - imagine buying something, then when you get to the receipt page, it gives all the information about the transaction, ready to go into your financial management software, or into a program to keep track of the packages being shipped to you.
Then again, this may be because I hate Intuit with a passion...
Looking at the examples on the Google page (http://www.google.com/support/webmasters/bin/answer.py?hl=en...) of marking-up breadcrumb links though there is a clear step away from clean functional markup. It looks like the sort of code people make (have made) to add styles to containers and what not. Couldn't semantic info be simply added in any tag available thus:
<a href="/a.htm" typeof="breadcrumb1">a</><a href="/b.htm" typeof="breadcrumb1">b</> ...
Why would that be so hard?
Perhaps further detail could be added by having a typeof-sheet that references the id of a node and details the information it presents (like external CSS).
Microdata provides a less horrific way to express the data in question.
If you think about it, a big part of the appeal of facebook is that, for many people, it solves all the actual problems semantic markup is supposed to be able to solve.
AFAIK the goal of XHTML was extensibility and interoperability with other data formats, by allowing arbitrary XML elements from other XML namespaces to be embedded. It seems to me that this solves exactly the same problem (as microdata) and more in a much cleaner way. Why invent yet another format?
Worse, marking up my data in the database from which I serve my web pages may benefit me, but currently, marking up my data in my web pages just costs bandwidth.
Yes it did provide great benefits that are now being destroyed. The benefit was that we actually had working, up-to-date XHTML parsers in each and every programming language. Message to web designers: Some people have to parse the crap you put in those pages and it's not just the browser makers! I know HTML parsing was never an exact science even with XHTML, but at least we were moving in the right direction.
It's been 11 years since XHTML recommendation was published, and you still can't rely on XML parser for reading content on the web. Even documents labelled as "XHTML" are often ill-formed (and almost all of them are sent as text/html). Even if we were moving in the right direction, we were moving too slowly. Now that HTML5 parser is specced, it may be quicker to add it to popular languages than turning whole web around.
I don't understand why we need yet another slightly incompatible pointy bracket syntax. Adding that syntax to all languages and ironing out all the quirks will take years and it won't replace the existing mess. It will just add to it. I see no progress at all. It's a pointless waste of resources.
Microformats and microdata don't obey the first law.
Why Publishers Fear Metadata
Stop thinking it's limited to web browsing.