Earlier I made a comment about how I wished there was a better way to connect microformats to web services. I’d like to elaborate on that comment and see if I could get some discussion going around the subject. First let me summarize the problem. (Note that throughout this post I will use the term microformat, but all these problems hold true for RDF as well)
The problem is that there is no standard way (that I’ve found) to interact with various web services that deal with the types of data involved in microformats. Note that in some cases there are standard data interchange formats (like vCard and iCal), but the web services do not always accept these formats.
The way Operator solves this problem through the use of user scripts that implement actions. What these actions do is take the microformat and use the data to construct a URL (or even a POST request) that connects to the appropriate web service. For instance, if I want to add my hCard to to the Yahoo! address book, the URL might look something like this:
http://address.yahoo.com/?ln=Kaply&fn=Michael&co=IBM
&e=nospam@example.com&pu=http://www.kaply.com/weblog/&A=C
In this case, the user script has taken apart the microformat and then constructed a URL that emulates adding a Yahoo! Contact. In doing this, lots of code was involved because the Yahoo! Add Contact does not map completely to the data that was in the microformat (you can see that code in yahoo.js). (Folks might ask why I’m not using Yahoo! APIs – that’s mainly because I don’t want to mess with authentication keys and stuff – this is a web interface, so I’d rather just redirect to websites)
The problem with this code is that in order to express the mapping from a microformat to Yahoo!, I require a large chunk of code.
For Firefox 3, I want to provide some UI that connects microformat to web services, but I want that to be extendable by third parties. I want it to be similar to how feed readers work in Firefox 2 (see registerContentHandler). While my action architecture works in the context of Operator, I do not believe that it is robust enough to be a part of Firefox 3. So what I’m trying to find is some better way to describe the mapping between microformats and web services or possibly to create a new standard around interacting with these web services. It might be as simple as just encouraging all of the vendors to accept the upload of vCard and iCal. I don’t know. Here are some thoughts I (and others) have had.
Encourage people to support the submission of vCard and iCal in a standard way
The obvious thing to do here would be for services to allow the submission of vCards and iCals directly to their web services as a way to provide information to the services. 30 Boxes currently allows this, but unfortunately the iCal must be physically located on a web site, so I can’t send it to them. Other services that accept vCards use a POST mechanism that is difficult to emulate because it relies on lots of private data during the POST submission.
Server Data Broker
Setup up a web service that would essentially act as a data broker. Data could be given to this server in a standard way, and then the server would turn that data into a URL that could be used to redirect to the appropriate web service. In this way, the logic to turn the microformat data into a URL would be done on the server. The client would give some common data source to the server, telling the service where it wanted the data to be sent and the server would simply send the client a redirect URL.
OpenAction similar to OpenSearch
S. Sriram had an interesting thought in reply to my previous post. He thought about using something similar to OpenSearch where web services can have an XML description file that describes how to interact with their services and then we could use that file to determine how to map the microformat data to the web service.
Those are just a few ideas we’ve come up with. I’d love to hear any other ideas you might have…