InfoPath Dev

Have this browser enabled form as a content type in a MOSS 2007 document library. There's an alert set up for when new forms are saved to the library, an email is generated and sent to a user. The email arrives indicating a new item has been added like I expected it to. In the email, there's a link to view the newly created form. However it's in an XML format. The link says "View {name of saved file}.xml" 

When I select the link, an error message is generated, the form doesn't come up. The "details" of the error message are "The URL is an unsupported relative URL. Use an absolute URL or prefix with ~sitecollection for the site-collection-relative URL."

Swell.....

When I go the document library via a web browser, navigate to the library and click on the entry, the form comes up just fine. So it's only when I click on this link from the email. Any suggestions, thoughts appreciated.

That's because Forms Services URLs are much different than the file URLs.  It works when clicking on it from the form library, because the form library knows to open it in Forms Services.  However, a directl link to the XML file in email doesn't know what to do.

You should create your own workflow that sends notification emails and has the full Forms Services URL dynamically generated so that when people click on it, it opens directly in the browser.

Well..why does it work with Word Documents.  You know what I mean?  If I create a Word doc in a library....set an alert for new items, when I recieve the email and  I can click on the link in the email and the word doc comes up. Is that because IE and Word are integrated together more so?

Because Word is not a browser-enabled InfoPath form being rendered in Forms Services.  You're talking about browser forms here.  Regular rich client forms will open just fine just like Word when linked from email or anything else.

The particular error you were getting about relative vs absolute I've never seen, but the root issue you have is auto-linking browser forms, which requires much more than the direct URL to the XML file.

Okay...that all makes sense.

 Actually all the business about relative vs absolute was a previous problem I was having, which I fixed from a MS Exchange hotfix. Prior to this rendering issue, I couldn't even open up the email message being generated and ultimately sent from Exchange. It was a MOSS 2007 / Exchange 2003 compatibility of sorts issue. The hotfix resolved that issue. Why that same detail error message is still being displayed with regards to the rendering stuff, is beyond me.