What InfoPath Is Not

Sometimes it is helpful in defining the capabilities of a piece of software to spell out what it does not do, and specify how it differs from some tools that might already be familiar. This section is written not to put you off using InfoPath 2003, but to help you form a realistic appreciation of purposes for which it is or is not well suited.

InfoPath Isn't a Browser Forms Tool

InfoPath uses a proprietary client, both for the design of form templates and for the filling-in of forms. Thus, neither the advantages nor the disadvantages of Web browser forms necessarily apply to InfoPath form templates.

Some potential users of InfoPath find it surprising that InfoPath forms cannot be filled in using a conventional Web browser. However, the InfoPath client uses a form definition file, the .xsn file, which a typical Web browser doesn't know how to handle. InfoPath works with the .xsn on the fly in ways that a Web browser can't. To learn more about the .xsn (form template) file, see Chapter 15, "Understanding the .xsn File."

If you want to create forms solutions deliverable via a Web browser and you want to use XML, you have the option of creating ASP .NET Web Forms solutions (but you will have to handle issues such as the marshaling of name -data pairs into a suitable XML structure). An alternative approach is to use W3C XForms, which handles the XML aspect of the solution automatically, but at the time of this writing lacks XForms design tools.

InfoPath Isn't a Specialized Database Query Tool

InfoPath 2003 has great wizard-based connectivity to Microsoft Access and Microsoft SQL Server databases. InfoPath can, using the wizard, query more than one table at a time. However, if you attempt to go much above two table queries, you might receive error messages indicating that InfoPath has been unable to automatically create the query that you are interested in.

In principle, you can hand-code SQL inside the form files that InfoPath creates. However, in practice, you might be wise to treat the inability to create the queries you want to execute as an indication that you should be using another client. For example, you might want to consider whether using Microsoft Access as a front end to an SQL Server database is a more appropriate approach.

InfoPath Doesn't Handle All XML Web Services

The InfoPath 2003 client cannot handle all XML Web services. It can't process remote procedure call XML Web services. It also does not handle SOAP documents that use an inline W3C XML Schema document. InfoPath requires a separate W3C XML Schema document to exist as one of the files contained in the form template file (the .xsn file).

InfoPath form templates can, in principle, connect via XML Web services to any back-end system. The difficulty arises when you attempt to access XML Web services that don't take into account which XML Web services InfoPath supports.

InfoPath Isn't a Windows Forms Tool

InfoPath also differs from the custom Windows Form solutions that you can create using tools such as Microsoft Visual Studio 2003. Users have a standard interface with InfoPath 2003 forms, whereas custom Windows Forms solutions may require the user to master a new interface. InfoPath can provide solutions to many situations where Windows Forms solutions would work, but not all. Windows Forms can be used, but at a cost, to provide solutions of which InfoPath 2003 is not capable.

Unlike the current generation of Windows Forms tools in Visual Studio .NET 2003, InfoPath makes no routine use of .NET technologies.

InfoPath Isn't a Smart Document Tool

Microsoft Office System 2003 includes smart document functionality in Word 2003 and Excel 2003. Such smart document solutions use XML, but in ways different than the use of XML in InfoPath. InfoPath provides automatic validation of data, functionality that is not typically present in all smart documents.