David Janes and friends over at microformats.org have written an inspiring greasemonkey script that will find microformat structures on web pages. They include some links to pages with hCard and xFolk content.
When content in a supported microformat is encountered on a page, the script embeds a visual indicator like this one for hCard 
which when clicked produces a context menu. The functions on on the context menu depend upon the microformat. The menu for an hCard includes an “add to address book” item that will invoke Microsoft Outlook to create a contact.
Perhaps the most interesting thing though, is the menu item to map the vCard address with Google Maps. How many times per week do you grovel around the web for some physical coordinates only to then select-copy-paste into the browser search box, the first line of the address, then select-cut-copy-paste the second line in order to generate a map page? The “show on Google Maps” item does it all in one swell foop, taking you directly to the map!
dschud’s COinS-PMH shares with microformats the ability to embed into a static page, sufficient metadata and structure, to support extended processing without any need to re-invoke the web application that produced the content. But what does “extended processing” mean in this context? It means doing something with that content that the originator could not foresee. In the case of the microformats example it means a greasemonkey script. In the case of COinS-PMH the primary example is a “hacked ‘COinS Details’ sidebar”.
So repurposing content, conveniently, in ways unforeseen by its originator is what its all about. The greasemonkey script and the sidebar provide a glimpse of what’s in store. How much unforeseen functionality do the browser add-ons really provide though? In terms of scalability of functionality, should we expect the plug-ins to keep growing to encompass more functionality? For instance, should the hCard script grow to support mash-ups with more web applications beyond Google Maps? How about adding a function to send hCard holder a gift from Amazon?
The beauty of the hCard-Google-Map-mashup-script is that it didn’t require Google’s web app to understand hCard. The script-mashup did the translation. But that translation is at the heart of the scalability shortcoming. If the script has to contain mappings from each microformat to each way I want to use content conformant to that microformat then the opportunity for explosive functionality growth is missed. If on the other hand, the target web application understood the microformat in question, and we had a way to feed the target app conformant content then the scalability bottleneck would be broken. The wheels would be greased.
In a previous post I proposed the notion of a web app clipboard. The basic idea was that AJAX could be used to request content from a source application. The content would land on the operating system clipboard in a simple format (the web app clipboard format) and could then be transmitted to a destination application. Now I’m thinking that the original proposal was overbold. As Ryan Tomayko intimated, there ought to be a way to marry the microformats approach with the web app clipboard. Perhaps its profitable to think initially in terms of the source content being scraped directly off the page, without requiring the additional request to the sourcing web app. We’ve got that functionality in hand. With that in hand we could focus on the other side of the equation — where to send the content. The effect would be that we would no longer have to create both producing and consuming applications — we could start with just consuming ones. Anything that increases the likelihood that two web apps will communicate is a Good Thing. I’m with Phil Bogle and others who’ve pointed out that we need to bootstrap by finding those first two applications.
If a menu item called “copy” was added to the hCard context menu of the greasemonkey script, and that item caused the hCard to land on the operating system clipboard in a simple standard format, then it would just be a question of where the content could be pasted. Then our task is reduced to inducing a few web apps to support the paste action. A really simple first approach to paste support doesn’t even require XMLHttpRequest at all. A receiving web app could simply provide a text box wired to understand the web app clipboard format wrapping an hCard for instance. Paste into a text box works “out of the box” with all browsers. It’s not all that elegant, but it would work.
Giving microformats a place to go (destination applications) and a simple way to get there (the web app clipboard) will break a key bottleneck hindering broad interoperability.