InfoPath 2003

InfoPath 2003 - XML Forms Processing++

Microsoft developers have to tread very carefully. They want to meet their customers demands that their products be open and interoperable but they do not want to stray too far from the Windows Server and desktop core that is the wellspring source of Redmonds unrivalled profitability and huge $50B cash surplus. The company has appeared to hit on a compromise solution - data interoperability will be provided through XML and a few other well chosen data interchange formats. Remote access to data will be allowed to be delivered by MS developers through the Web Services mechanism not CORBA, not Direct-RPC, and definitely not J2EE. And in general, programming interoperability is firmly discouraged both on the desktop and through the Web Interface. Programming interoperability might make it too easy to move applications to other OS and thus Java, JavaScript, and other cross platform programming languages have been "proprietized" as in JavaScript to JScript; the wealth of VBscript clones to VBScript and VBA; and Java to C# among others. Thus InfoPath which delivers XML-based data interchange and interoperability on the Windows desktop is obviously of interest to see how and how well XML-based data interoperability will be delivered.

First and foremost InfoPath's development has been championed at Microsoft by one of XML's pioneers, Jean Paoli. And Paoli has managed to adhere very closely to W3C XML standards in the implementation of InfoPath.An impressive array of XML standards are used: XSD, XPath, XSLT, XML Namespaces, XML-DSig, XHTML. Second, InfoPath is being labeled as an example of the new wave of Microsoft "smart client" applications that take advantage of the rich Windows API . Thus Infopath's GUI interface is designed in very novel ways for adding value to the desktop as primary player over the competing and increasingly popular web interface. Conditional form blocks, dynamic formatting of fields, and user triggered, expanding records and forms are some of these key GUI innovations.

Third, InfoPath is able to interface and interoperate with both Microsoft and non-Microsoft Windows desktop applications and heterogeneous server applications through XML schemas, XML Web Services and ADO database connections(but only to Microsoft databases in this case). Finally, InfoPath is a relatively good Web citizen - not just adhering to many W3C XML standards but also able to interact through IE using scripts based in either JScript (adhering to ECMAScript standards and very close but not identical to JavaScript) or VBScript while its XML-based output is publicly available to other browser or application vendors through XML schemas. This is a heady mixture. Infopath attempts to (and so far does reasonably well - but see our section on XML Departures)adhering to web and data integration standards while advancing the proprietary Windows desktop - primarily by acting as a forms filler as well as form designer. Infopath is also an XML data integration point along with Word 2003 and Excel 2003. All things considered, this is a remarkable piece of software well worth examining for the impact it will certainly have on desktop, Web and XML development.

What InfoPath Does

InfoPath is a Windows 2000 and XP-only desktop forms designer and filler application that uses XML to interface with a variety of data resources. InfoPath sports a full Windows form designer with drag and drop ease plus scripted validations in a full IDE. The designer portion of the program can be hidden so end users just access the forms filling features. In addition InfoPath sports some novel conditional/dynamic forms elements. InfoPath users can complete forms online or offline. This latter capability sets Infopath apart from most Web-based applications like HTML forms or PHP, JSP, and even Microsoft's own ASP. However, some of the newer RIA tools sport this online/offline capability using either Flash or Java runtimes for offline operations.

But Infopath forms are quick and easy to fill out in either offline or online mode. InfoPath forms easily allow re-using stored data in a variety of forms/reports because its own data is stored in XSD described caches. This means any program with XML savvy with the correct permissions can access InfoPath forms and data .InfoPath uses Internet Explorer's security zones and levels for access control. Depending on your organizations security preparations, this may or may not be adequate. However, other than digital signatures, InfoPath does not provide any other on board XML access or security provisions.

Frontline Security Concerns

Because Infopath acts as a data integrator by redirecting/repurposing gathered data either through built in Web Services or ADO or other XML transformational and delivery services - InfoPath can become a front line agent in an organizations security profile and frontier. Unfortunately InfoPath's almost total dependence on IE security zones and levels leaves it vulnerable in some shops. InfoPath competes directly with Adobe Acrobat and variety of other forms tools and it leaves something to be desired in the data security arena. Lack of built-in security other than digital signatures (which does not prevent but only signals unauthorized alteration of data) leaves InfoPath comparatively more vulnerable

Access control, encryption, and levels of authentication are available from the competing forms tools. Some of these tools use proprietary methods; others use some of the emerging XML standards for on board from security. InfoPath relies primarily on the client operating system or Web Servers such as SharePoint, IIS, Windows Server to provide these security services. So by its very nature as a forms tools but also because it has solid scripting, data validation and reporting capabilities, InfoPath scrapes up against database and web development tools like Access, ASP.NET, PHP/Perl/MySQL, JSP/J2EE and others. We would rate InfoPath the least inherently protected and secured tool of all the forms processing capable tools we have mentioned.

Operational Testing of InfoPath

We installed a copy of Infopath on a Windows 2000 machine with the required SP3 patches without a hitch. We were able to create our own forms very quickly and then complete them plus a host of pre-compiled forms. This testifies to the inherent ease of development of InfoPath. We were able to utilize the repeating sections and conditional form field features of InfoPath in very short order. Use of the dynamic fields, validations using JScript, plus form templates was also fairly easy; but partially that comes from being a big time Macromedia Dreamweaver user and thus making some astute/educated guesses as to how InfoPath's Designer worked. Not all developers will be so lucky.

However, we were impressed that Infopath comes with a complete Scripts editor (looks like a clone off the Visual Studio block) so we were able to add scripts and debug them in relatively short order. However there were some problems. Microsoft Script Editor in InfoPath does NOT have Intellisense and thus getting the syntax right is a bit more difficult. Coders familiar with JScript and Visual Studio will be at an advantage. On the data integration side our experiences were also mixed. Access through XML, as previously noted is straight forward. Ditto for Web Services in an implementation that really smooths what could be a process fraught with errors.

However, on the ADO connection side we got a rude surprise. We had fully expected an ODBC and any database connection; but InfoPath has taken a proprietary route - only supporting Access and SQL Server databases through a special ADO connector. This reviewer really deplores Microsoft's unexpected, artificial and proprietary misdirections. This short-changed data connectivity is definitely one of those. For a $32B company - who needs this pettiness when data integration and interoperability have been and continue to be the number one IT priority.

XML Wizardry

Despite the security and data connectivity gaffes, InfoPath is a testament to the XML wizardry possible from redmond. There are some impressive feats. For example, InfoPath's use of an XML file can have a XML Schema auto-genned for it. Making the Web Services connections the WSDL Schema are automatically read and prepped for connections to InfoPath. In making basic form interactions, InfoPath auto generates XSLTs to make form view correspond to structure schema view. Each one of these alone is nifty innovation. Add these to the conditional fields or auto-expanding table row capabilities and it is no wonder InfoPath catches reviewers attentions.

But despite these accolades, Infopath also falls off the XML Standards Wagon - and in fundamental ways. For example, InfoPath does not use XForms nor SVG for drawing/rendering forms, figures, and controls despite the fact that these XML standards have been available for some time and recently updated plus adopted by a number of vendors. Not using these standards means Microsoft developers have yet another incompatible GUI form to contend with. There are now 5: WinForms, WebForms, old VBForms, VBAForms and now InfoPath forms. This forms sprawl will hopefully be consolidated under Longhorn's XAML and the new Avalon GUI API - but don't count on it.

The other missing XML link in InfoPath is the lack of XACL-XML Access Control Language for access control and XML Encryption for encoding . InfoPath ut defers to Windows Server based ADS and other identity/access control services and really does not directly draw on encryption services. There also some proprietary excursions as well. InfoPath goes beyond current XSD schemas to add its own custom declarative constraints in addition to scripted constraints and validations. So although InfoPath shows some very creative use of XML, it also leaves some serious gaps, particularly as noted above, in security.


InfoPath is somewhat frustrating. In its basic core application of of XML there are shining glints of brilliance mixed in with proprietary fools gold. No database access except through Web Services but special direct connectors for Microsoft's own Access and SQL Server databases. Lack of true built-in security in the form's runtime. But also there a whole set of small missing features. For example, there is no free/low cost form filler version to match Adobe Acrobat reader. No Pocket PC version - and no apparent plans. No planned support for scanned paper forms like Omni Forms.

But perhaps beyond the security gaps, the other most disconcerting factor is the lack of a cross platform InfoPath runtime engine that would allow InfoPath forms to be used on other popular OS. Contrast this with the other popular form-filling software: Adobe Acrobat and the upcoming Flash/Flex player. Both of these runtimes work standalone or in a browser on all the major OS including all flavors of Windows (unlike InfoPath which abandons Win 9x), Mac, Linux, Solaris and most popular Unix flavors. Even worse the InfoPath "runtime" is somewhat bloated because it includes the full designer executable code (largely inactivated). This adds to the bulk of the InfoPath. Although Microsoft insists the requirements are 128MB of memory and a 233Mhz processor let me suggest for consistently good response time you will need a 750MHz Pentium or better with at least 256MB of memory. Our test machine just barely matched these requirements and we found it to be generally fast; but decidedly slow on some operations(response time slowing by a factor of 3-5 times).

Therefore this is the bottom line on InfoPath. InfoPath is FormsProcessing++, but with some flaws.If you are a Microsoft shop, wait until the next version comes out and the security is shored up and a smaller runtime is available. For cross platform IT shops wait until the smaller runtime also supports cross platform operations. In the meantime watch and see if Cardiff or Adobe Acrobat can match the innovative conditional and repeating fields of InfoPath while the race for robust cross platform offline and online forms is an open contest.

 Top of Page  Open Sourcery Home    
©Imagenation 2001-2004