Rather than try to guess "why a new format?", I'd prefer to take a minute to examine whether it would have been possible to use OpenSearch to achieve the same end. Superficially, it seems like it would be possible, considering that OpenSearch was intentionally designed to be extensible and the specification was released under a Creative Commons license to encourage reusability. But perhaps I'm missing something -- if so, this is a good opportunity for me to improve OpenSearch so that other people won't have to create new formats in the future.
Let's take an example "Custom Button" declaration -- in this case, the Custom Button for Slashdot. The XML for the Slashdot custom button reads:
<?xml version="1.0"?>
<custombuttons xmlns="http://toolbar.google.com/custombuttons/">
<button>
<site>http://www.slashdot.org</site>
<search>http://slashdot.org/search.pl?query={query}</search>
<title>Slashdot.org</title>
<description>
News for Nerds. Stuff that Matters: daily digest for tech community to discuss, debate, and scrutinize.
</description>
<icon mode="base64" type="image/x-icon">
AAABAAEAEBAAAAEAIAB... [binary data snipped] ...AP4/AAD//wAA//8AAA.==
</icon>
<feed refresh-interval="3600">
http://rss.slashdot.org/Slashdot/slashdot
</feed>
</button>
</custombuttons>
At first glace, this is analogous to the OpenSearch Description document.
Let's compare the Custom Button elements in turn to see if there is something missing from OpenSearch. (Note that some of these are not exactly direct mappings, but can be used to do the same thing.)
| Custom Button | OpenSearch | Meaning |
| title | ShortName | "The title of the custom search button that the user can see in the list of custom buttons." |
| description | Description | "The tooltip text of the custom search that the user will see if they hover over it with a mouse." |
| site | Url | "Optional URL to navigate to when there is no new text in the search box." |
| search | Url | "The URL that the browser will navigate to and search when the button is clicked with a "new" search term in the search box." |
| send | Url + Extension | "Optional URL the browser navigates to when there is no text in the search box and the user has selected text in the browser window." |
| icon | Image | "The actual bits of a Windows-style .ico file." |
| feed | Url | "Specify a URL to an RSS 2.0 or Atom Feed 0.3/1.0 XML file." |
| feed-icon | Image + Extension | "An alternate icon to display when the feed has new items." |
| feed-description | Extension | "An alternate description to display in the tooltip when the feed has new items." |
| update | The OSD URL | "The URL where this button definition was downloaded from" |
| option | Query Syntax + Extension | "Specifies a locally defined option string that the user can easily change in the toolbar settings dialog box." |
Additionally, Custom Button supports a "locale" attribute, which functions in similar ways to the language and encoding attributes in OpenSearch.
At first glance, there are a number of one-to-one mappings between the Custom Button format the OpenSearch format. But if you look deeper, even some the missing bits are accounted for. In particular, all parts of OpenSearch explicitly include a way to extend their core functionality. In fact, OpenSearch was intentionally designed to be minimal in its base implementation, and encourage third parts to extend it for just this type of application.
So what would the Slashdot "button" look like as an OpenSearch Description document? I.e., could we have achieved the same results using OpenSearch instead of inventing a new format?
A hypothetical "Custom Button" for Slashdot, in OpenSearch format:
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
xmlns:google="http://toolbar.google.com/custombuttons/">
<Url type="text/html" template="http://www.slashdot.org"/>
<Url type="text/html" template="http://slashdot.org/search.pl?query={searchTerms}"/>
<ShortName>Slashdot</ShortName>
<Description>
News for Nerds. Stuff that Matters: daily digest for tech community to discuss, debate, and scrutinize.
</Description>
<Image height="16" width="16" type="image/x-icon"/>
http://slashdot.org/favicon.ico
</Image>
<Url type="application/rss+xml" template="http://rss.slashdot.org/Slashdot/slashdot" google:update="3600"/>
</OpenSearchDescription>
So the quick answer appears to be yes, the Google Toolbar could have used the OpenSearch format to achieve the same goal. For my example I needed to create an extension namespace to handle the "update" interval on the RSS feed, and I had to establish a convention for URLs that don't contain search terms. But those scenarios were both supported, and in the end it was trivial to use OpenSearch in this context.
It would have been nice to see Google reuse OpenSearch in their toolbar. If they had, then the Google Toolbar search plugins would have been compatible with not only A9.com, but also Internet Explorer, which is using OpenSearch extensively in IE 7. (And from what I can tell, Firefox will be adding OpenSearch as a plugin format as well.)
That said, I'm not a fan of format zealotry. Examining the compatability and similarity between formats was a fun exercise, but nothing to get worked up about. Though perhaps more of us can start working together on these types of things in the future.
By the way, I really like that the "custombutton" format uses lowercase and hyphenized element names. I thought about trying to do this with OpenSearch 1.1., but in the end it seemed to make more sense to minimize the number of changes between versions. This can definitely be reconsidered for future versions.
If you're interested in helping out with OpenSearch, please join us on the OpenSearch mailing list and let us know how we can improve things.