File Paths in Desktop Search

In previous posts, I've been telling people to use the System.ItemDisplayPath and System.Filename to create the full filename.  I also complained about some anomalies I had come across with the file paths.  You see, there is no field that just contains the filename with path.  My guess as to why this is the case, is that WDS is not just files -- it's also email, journal entries, contacts, and more.  So the universal scheme is the URI, stored in the System.ItemUrl property.  This is fine for the Windows Shell.  I can invoke Shell.Execute on a URL and it launches perfectly -- not just for files, but even for the non-file types.  This works because of ProtocolHandler's.  They are invoked based on the format of the URL, and they can break apart the path and "do the right thing" like showing a contact or image.

I posted to the MSDN Desktop Search forum and got the response that the *Display* properties should never be used the way I am.  They really are just for displaying.  It seems a bit funny to include display items in a search index.  Should the application worry about that?  Anyway, the official response was to use System.ItemUrl and do my own parse to turn it into a filepath.  Apparently that's what the Shell does.  If the various API calls and Framework objects could handle a URL, it wouldn't be an issue.  So when you get:

file:c:\folder\file.ext

or

otfs:{12345-12355-12345-1245-12345}//n/documents/file.ext

It's up to you to parse it into a path to use.  By the way, "otfs" is how network files show up in the index.  It's not difficult to parse, but it seems like it shouldn't be necessary.  Even if the index does handle more than files, I think it still makes sense to store the filename (or NULL for non-files).