The next version of Microsoft Office is, among other things, a family of XML editors. I have discussed the XML modes of Word
and Excel (see "XML for the rest of us" and "Exploring XML in Office 11"), and described the newest member of this family, InfoPath 2003, a tool for gathering XML data (see "Ten things to know about Xdocs"). Now that I've had a chance to work with Microsoft InfoPath 2003, Beta 2, its role and value are becoming clearer.

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
|
 |
|
|
|
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 nongeeks 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.