Справочник Пользователя для Wiley Professional InfoPath 2003 978-0-7645-5713-2

XML Forms

Consider first the very general example of the expense or travel claim. Suppose Human Resources has
given you an electronic copy of an Excel sheet that will work everything out for you. You  fill in the
blanks and  print it out. Then you put it on your manager’s desk so she can sign it. Eventually, it gets
to Payroll, where someone else enters some or all of the data again.

Now you perform the same task, this time using InfoPath. Instead of a spreadsheet, you download a
form template to complete. It also does the necessary calculations. You e-mail it to your manager, who
approves it with a digital signature and routes the form to anyone else who needs to sign. The XML data
is harvested by the payroll system, and the repayment gets added to your pay slip in time for the big
weekend you have planned. This by itself is probably a sufficient motive for any developer to learn
InfoPath and implement a new staff expenses system.

From a less selfish perspective, think of the thoroughly forms-intensive business processes where data is
still bound up in paper-based systems. If you have ever worked for an insurance company, a financial
services firm, a hospital, or a government department, you’ll see the huge potential in unlocking the
data carried in office forms.

But without a doubt the most attractive feature of InfoPath is that you can hide the complexities of XML
from end users. Even if you understand XML, it can get in the way. A while ago, one of us explored the
idea of introducing XML capture for a large group of developers working on a complex API. It would
have made the creation of an HTML reference easy, but while everyone saw the validity of the business
case, they rebelled at the thought of using a traditional XML editor. If InfoPath had been available then,
no doubt they would have been more supportive.

Microsoft isn’t the first, let alone the only, vendor to spot the opportunity for forms tools, and there will
be plenty of competition for this very large market segment. Microsoft may have an advantage, how-
ever, because of its dominant position in the office market.

To put InfoPath in context, we suggest you take a few moments to look at the alternatives there are to
the approach that Microsoft has taken. Several observers and commentators have compared InfoPath to
XForms, a recent W3C Draft Recommendation intended to be integrated into other markup languages,
such as XHTML or SVG. See, for example, Michael Dubinko’s XForms and Microsoft InfoPath at
www.xml.com/pub/a/2003/10/29/infopath.html.

Perhaps the comparison is made because there is an implied expectation that forms processing should
mainly follow the Web processing model. You may or may not agree that the Web is the natural home for
forms, but in any case a direct comparison just isn’t productive. As Dubinko points out, that’s because
InfoPath is an application, whereas XForms, together with a number of other interface markup lan-
guages, is an XML vocabulary.

It may be more helpful to look at points of similarity and difference adopted by developers of XML
forms applications, including XForms. 

When it comes down to it, XML forms processors have more in common than you might think.
Essentially, they are there to convert user input into new or modified XML data, which can then be
routed through a series of business process, possibly on multiple platforms in different organizations.

2

Chapter 1

01 557130 Ch01.qxd  3/18/04  3:59 PM  Page 2