The next version of Microsoft Office is, among other things, a family of XML editors. Now that I’ve had a chance to work with Microsoft InfoPath 2003, Beta 2, its role and value are becoming clearer.
As thousands of recipients of the Office 2003 beta kit have already discovered, InfoPath has none of its behemoth siblings’ heft. Yes, it’s an Office app, but it’s a new Office app, one that doesn’t have to haul along 15 years’ worth of accumulated cruft. You don’t have to think twice about launching it. And it could probably work well as an embeddable component —an option that many would welcome should Microsoft choose to offer it. It’s best to have a real project in hand when trying out new software, and in this case, I did. I’m working out the details of the XML API that is the Safari Books Online equivalent to the Google and Amazon query interfaces. InfoPath’s creator, Jean Paoli, insists that the product is not a schema designer, and now I can see why. You can use the product to create a simple schema, and it will validate against any schema, but designing a complex schema is beyond its ken.
In my case and in a great many business-relevant scenarios, that detracts little from InfoPath’s value. That value is simply stated. InfoPath enables non-geeks to define simple XML templates, then hand them to users who can fill them with real data. Through an iterative process of template refinement and data gathering, designers and users can collaboratively work out how the data wants to be shaped. No programming needs to happen until that cycle yields something worth the investment of programming effort. At that point, the pros can enhance the basic (but standard) XML Schema that InfoPath has produced, arrange fancy ways to distribute InfoPath documents, collect them, and weave those documents into business processes. InfoPath’s genius lies not in its individual parts, but in its collaborative whole.
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.
The paragraphs of text in Screen 2 are bound to a rich-text edit control. It delivers well-formed XHTML output, which InfoPath stores in a properly name-spaced element in the XML data file. That’s the good news. The bad news is that this editor is otherwise not much of an improvement over the widely used and much-maligned DHTML edit control, which emits horrid HTML cluttered with inline font tags and other junk.