7 on 7: Federated Search
It’s a stuffy-sounding name, but I’m finding the Federated Search capability in Windows 7 rather cool, and starting the see all kinds of uses of it to improve my own productivity.
Federated Search leverages the OpenSearch API and the common syndication formats of RSS and Atom to enable searching of enterprise and internet sources directly from Windows Explorer, with the results displayed just as if they were files on the local file system.
How it Works
The premise is rather straightforward and is captured by the diagram below (with explanation following).
You first need to install a search connector in the form of an .osdx (OpenSearch description) file. It’s simply an XML file that follows the schema detailed here. Windows 7 has a file association for an .osdx already so when you double-click an .osdx file or download one from the Web, it will install the search connector for you. [If you’re itching to do that now, there’s one for Channel 9 that you can download here].
Once the connector has been installed, you’ll see an option in Favorites that will access the search capability. This is actually just a shortcut to the real connector that’s been copied to your user profile’s Searches directory.Presuming the connector isn’t set up to automatically search, like say provide the most recent 10 posts on Channel 9, you’ll need to add your search criteria in Windows Explorer.
What you’re actually setting in motion here is a call to the search provider specified in the .osdx file. For Channel 9, it’s just a straightforward URL:https://channel9.msdn.com/Search/feed/rss/?Term={searchTerms}In this scenario, what I typed into the search box in Windows Explorer (Northeast Roadshow) is substituted for the
{searchTerms}placeholder, and the HTTP request is sent over the wire.The Channel 9 search service then does its job and returns results in RSS format. If you have "Feed Reading View" turned off in Internet Explorer, you'll actually be able to see the raw markup just by entering the same URL in a browser.
Given that RSS (and the alternative Atom) feeds are well-known formats, Windows Explorer can parse the output and assign semantic meaning based on the various tags. For instance, the
<title>tag is an obvious choice for the main item of the search result, and<description>seems pretty clear too, so you end up with the results below.
Customizing the Display
Now comes the fun part. You actually have a bit of control over what information is displayed and where. One area you can customize is the Content View (the area showing information for each search result). That view can display up to seven fields, placed as follows:
Obviously, there’s a default placement and assignment of information from the feed to the various slots, but that can be overridden either in the search results (via additional tags embedded the Atom or RSS markup) or, conveniently, in the client .osdx file. If you open the .osdx file in Notepad or any other text editor, you can get a better idea of how things work.
Now, remember that the feed that comes back is the result of the URL referenced in the .osdx file, so there may be other information of interest in that feed that you want to surface within Windows Explorer. Three things that stand out to me from the RSS markup above are the number of views, the date of publication, and the link to the associated blog post, so let’s modify the output to include those.
The key to doing this is realizing that each slot in the layout can be occupied by a Shell property associated with the search item result. By coupling a known shell property with a specific data item in the RSS feed, you can populate the search result view as you’d like to see it. There is a default mapping of items in the RSS feed to shell properties which drives how the search results look now; here’s a few of them:
| RSS XML Path | Windows Shell Property (Canonical Name) |
| Link | System.ItemUrl |
| Title | System.ItemName |
| Author | System.Author |
| pubDate | System.DateModified |
| Description | System.AutoSummary |
| Category | System.Keywords |
But I’m looking to get a display something like the following, where I’ve highlighted the new items. Note, I also got rid of the size and tags fields.
What I need to do first is map the property values in the RSS to some Shell properties; the table below summarizes my choices.
| RSS tag | RSS namespace | Shell Property |
| pubDate | default | System.DateModified |
| evnet:views | https://www.mscommunities.com/ rssmodule/ | System.Search.HitCount |
| comments | default | System.OriginalFileName |
Additional XML added to the .osdx file captures this mapping:
The ResultsProcessing tag (unclosed in the snippet above) envelops tags to provide a customization of the base RSS results. That’s followed by a number of PropertyMap tags. Each of those names a Source property in the RSS (possibly qualified by a sourceNamespaceURI) and maps it to a Shell property, the name of which is the attribute of the child Property tag.
You might ask how I knew which Shell properties to use. While I couldn’t find a definitive resource, I selected these based on their relative correlation to what I was trying to display. Some Shell properties are used by the results processing step itself (like System.Item.PathDisplay) so you can’t use them.
Now that I have the source data mapped the Shell properties, I need to specify how I want them placed in the user interface. Enter another bit of XML:
The PropertyDefaultValues tag (which is another child node of ResultsProcessing)wraps the ContentViewModeForSearch property, indicating the intention to adjust the layout of the seven items in the search results line. You can adjust the layout in the details at the bottom of Windows Explorer as well as the tooltip, but that’s an exercise left to the reader!
The value for the property is the literal string “prop:”, followed by a semi-colon delimited list of Shell properties ordered according the field map above. You should always have seven Shell properties in this list; if you want to leave a slot empty, specify the property System.LayoutPattern.PlaceHolder, versus leaving it blank. Parsing the string in the snippet above and overlaying it on the ‘map’ results in something like this:
By default, the values will be preceded with a label that’s associated with it by the handler for that Shell item. If you don’t want to see the label, preface the property with the tilde character. Lastly, be sure there is no white space in this string, including preceding the “prop:” literal, or you’ll results will not display correctly (if at all).
Hopefully, if you wanted to follow along, you were successful in your venture. I’ve also uploaded the final .osdx file to this blog post in case you want to start there and deconstruct it.
Additional Resources
There’s definitely a lot going on under the covers here, and mucking with the base XML is error-prone (for me at least!). For more detailed documentation to help fill in the gaps, check out:
Federated Search in Windows 7 (MSDN)
Be aware too, that we really just discussed the client part. You can write your own WCF services that return Atom or RSS to provide a search over just about anything you like. You can even write a local provider that implements IOpenSearchSource. Just make sure you follow the OpenSearch guidelines and best practices as much as possible to ensure a smooth integration into the Windows Explorer experience.
Comments
Anonymous
November 03, 2009
Tank you for a well written and very useful article! Properly used federated search can be such a big improvement over existing GUI:s Thnx!Anonymous
November 03, 2009
Thanks for the kind words Joakim. I agree, it's kind of an undiscovered gem. I'm finding myself writing some of these connectors to streamline common searches... rather than open a website, enter info, etc., I can Windows+E and search. And I almost always have Windows explorer instance on my desktop.Anonymous
November 08, 2010
The comment has been removed