Mission accomplished

Starting points

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld Microsoft InfoPath 2003 Beta 2 Microsoft, microsoft.com Business Case: The Web services movement envisions a world full of SOAP endpoints, but it has not yet paid enough attention to one special kind of endpoint: the human being. When SOAP packets begin to flow through e-mail and reside on file servers and intranet Web sites -- as they inevitably must -- tools such as InfoPath will prove their worth. Technology Case: XML documents are the currency of the emerging business Web. InfoPath empowers business users to design those documents, fill them with data, and exchange them while guaranteeing the fidelity of that data and shielding the documents from the underlying XML machinery. Pros: + Intuitive, end-user-accessible tools for designing and gathering structured data + Built on open XML and Web standards + Automatically writes data definitions (XML Schema) and transformations (XSLT) Cons: - Advanced data validation isn't expressed in XML Schema - Rich-text editor not very capable - No built-in .Net programming interfaces Cost: TBD Platforms: Windows 2000 with Service Pack 3, Windows XP Ship Date: Summer 2003

When you launch InfoPath's form designer, there are a number of ways to jump-start a project. A prototype of the Safari XML API already exists, so I was able to point InfoPath at a query URL that returns XML results. As does Excel 2003, InfoPath can infer a schema from an XML sample retrieved from the file system or the Web. I separately tested InfoPath's capability of launching a new project based on data retrieved from a Web service. That works too, but only if the service uses document literal (vs. Remote Procedure Call) encoding.

You can also just fire up a blank form. That's what I ended up doing, although in retrospect -- once I learned how to manipulate InfoPath forms, views, and data sources -- reuse of a sample instance would have been more productive. But starting from scratch was pretty easy, too. A lot of the engineering work that's gone into InfoPath has focused on making forms, views, and data sources work in an extremely natural way for both the designer and the user. That effort has paid off handsomely.

Screen 1 shows the form I built to collect a package of search results and the schema governing that form. The structure is a sequence of books (with metadata), each with a sequence of sections (with metadata), each with a sequence of hits. You create the form by dragging elements from the schema window to the canvas. If you've defined an element as repeating, InfoPath suggests an appropriate container such as a table or a repeating section. When you specify font and layout properties, InfoPath applies them to the rendered form through which users enter data and to the HTML views it can optionally emit.

You can also specify validation properties, though these, I'm sorry to say, do not become part of the schema that InfoPath writes. Compare the Pubdate and Publisher fields in Screen 1. Pubdate, which uses a calendar control to receive input, corresponds to an xsd:date in the schema. But Publisher, which is constrained to a list of names in the InfoPath designer, maps only to an xsd:string, not to the enumerated set of values that XML Schema is capable of representing.

When the first version of my form was ready, I saved it as an .xsn file, which is just another name for a .cab archive. It contains a manifest, sample data (if any), the schema, one or more XSLT transformations corresponding to the views defined in the project, and a JavaScript shell for scripted extensions. Everything conforms to well-known XML and Web standards. You can publish the .xsn file to a shared drive, SharePoint, or any Web site. An InfoPath user who launches the file can begin entering data, as shown in Screen 2. The form grows hierarchically. In my Safari query example the user can add a new package of results for another book, or another section's worth of results to an existing book, or more hits to an existing section. Choosing File>Save yields a pure XML data file, which can in turn be launched into InfoPath. The schema and view-producing XSLT transformations are referenced from the XML, but the separation of data from presentation is cleanly and strictly enforced.