A Tale of Two APIs
Note that the foregoing discussion doesn't address the API model. InfoPath 2003 used a COM model that communicated through MSXML; however, InfoPath 2007 uses .NET instead. The two APIs are incompatible. You can get tips on how to convert from the 2003 model to the 2007 model by reviewing "Converting InfoPath 2003 Managed Code to the New InfoPath 2007 Object Model" (MSDN, June 2007). Just be aware that conversion is a manual process.
Perhaps the greatest changes in the object model are to the names of the root objects, such as things like the thisXDocumentobject disappearing and the change from an XML DOM-based reference model to an XML Navigator-based reference model. There are other changes, as well, such as how events are wired up. However, these events pale in comparison to the problems with learning a new set of root objects—and a completely new way of working with XML.
In regard to the change in root objects, the transitions aren't that hard after you get used to them, but if you've come from an InfoPath 2003 environment you may find yourself trying to use objects that are no longer there. When you go to reuse your previous code, or code you find on the Internet, it may be temporarily frustrating to learn how to convert the code into the 2007 model.
The transition to XML Navigator objects means you're no longer working with XMLNode objects. In truth, XML Navigator objects aren't really all that difficult. They're simply a pointer into the XML document, which can take a bit of getting used to because it's a new way of working with XML. For example, instead of extracting nodes using XPath statements, you move a pointer—a bookmark—in the document with a series of movestatements or XPath queries.
The real reason why you should care about the differences between the InfoPath 2003 and InfoPath 2007 object models is because despite the fact that the InfoPath 2007 client will support both object models, InfoPath Forms Services supports only the 2007 object model.
When you're confronted with an organization that deploys InfoPath 2003 and Microsoft Office SharePoint Server Enterprise Edition (MOSS-Enterprise), you encounter a fork in the road. You must decide to either use the 2003 model and use the InfoPath 2003 client, or use the 2007 object model and require that the form be filled out through Forms Services. This approach is complicated by the fact that InfoPath 2003 doesn't work with MOSS content types. Therefore, if you want to create a content type for InfoPath to use, you have to essentially use InfoPath Forms Services or the InfoPath 2007 client. Obviously, this problem will fade over time as more organizations replace InfoPath 2003 by deploying InfoPath 2007. The real trick is to make the decisions up front about what limitations that you're willing to live with and which ones you aren't.
A Matter of Trust
In today's world it's important, if not critical, to trust the code you're running. With viruses, worms, and Trojans coming out of the woodwork, you can't afford to run code today that you didn't write, didn't verify, or for which you don't at least trust the source.
The publisher sets the security level of an InfoPath form, and it is confirmed by the consumer of the form template. To set the options from the category list, the designer selects Tools --> Form Options, and then on the Security and Trust pane unchecks the "Automatically determine security level (recommended)" option and manually selects the level that is appropriate for the form.