Professional InfoPath 2003


What is this book about?

Microsoft InfoPath 2003 helps developers tackle forms-based information-gathering with the full range of XML technologies. This book quickly guides experienced Office and XML developers through InfoPath fundamentals, including XML form templates architecture, form definition file structure, available external data sources, and backend services. From there, you delve into validation and updating forms, both during development and as business needs change....

See more details below
Available through our Marketplace sellers.
Other sellers (Paperback)
  • All (11) from $1.99   
  • New (4) from $4.00   
  • Used (7) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2011

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

PAPERBACK New 0764557130 Your book ships the next business day.

Ships from: Cleveland, OH

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
Seller since 2011

Feedback rating:


Condition: New

Ships from: Murphy, TX

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2008

Feedback rating:


Condition: New

Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2008

Feedback rating:


Condition: New

Ships from: Chicago, IL

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by
Sending request ...


What is this book about?

Microsoft InfoPath 2003 helps developers tackle forms-based information-gathering with the full range of XML technologies. This book quickly guides experienced Office and XML developers through InfoPath fundamentals, including XML form templates architecture, form definition file structure, available external data sources, and backend services. From there, you delve into validation and updating forms, both during development and as business needs change. Finally, you examine the InfoPath security model, learning to implement and deploy trusted forms.

The second part of this book is an intensive case study covering metadata processing, exporting XML data to Excel for analysis, and much more.

What does this book cover?

Here are just a few of the things you'll learn in this book:

  • The development options InfoPath makes available through XML technology
  • How to combine various form files into a customized template
  • The architecture of an InfoPath form template and the file types you can use in various applications
  • Ways to build a form interface using menus or objects on the task pane
  • Methods to support users at various levels of experience
  • Different means of validating forms and reporting errors
  • How to implement digital signatures and other form security measures with InfoPath

Who is this book for?

This book is for experienced corporate developers who have a strong knowledge of XML and related technologies as well as solid experience with Microsoft Office and related applications.

Read More Show Less

Product Details

  • ISBN-13: 9780764557132
  • Publisher: Wiley
  • Publication date: 4/12/2004
  • Edition number: 1
  • Pages: 432
  • Product dimensions: 7.44 (w) x 9.26 (h) x 0.98 (d)

Meet the Author

Ian Williams is an information designer specializing in XML technologies and a software technical writer. He worked in the UK publishing industry before getting involved in information technology at OWL International, developers of one of the first commercial hypertext products. Ian was a product manager there, and later a consultant working with large corporate customers.
Since 1998 Ian has worked independently on technical writing and information design projects for customers like Nokia and Reuters. He lives with his wife in London, England, from which they regularly escape to a house on a beach overlooking the English Channel.

Pierre Greborio is chief software architect of PEWay, an Italian software company providing services and Internet technologies for financial companies.
Born in 1971 in Belgium, he graduated as a telecommunication engineer from the University of Pavia in Italy.
His activity is characterized by a strong passion for technology. He participated in several talks at developer conferences and university workshops and wrote several articles for developer magazines and user groups about Microsoft .NET technologies and Microsoft Office InfoPath 2003. In the beginning of 2003, Pierre was given the award of Microsoft Most Valuable Professional for .NET.

Read More Show Less

Table of Contents


Chapter 1: About InfoPath.

Chapter 2: Form Template Architecture.

Chapter 3: Key Form Elements.

Chapter 4: Meta Data Elements.

Chapter 5: Integrating Secondary Data Sources.

Chapter 6: Adding Business Logic.

Chapter 7: Back-End Services.

Chapter 8: Component Types and Controls.

Chapter 9: Upgrading Forms.

Chapter 10: Security.

Chapter 11: Customizing Forms.

Chapter 12: Introducing the Case Study.

Chapter 13: Input Data Structures.

Chapter 14: Implementing the Template.

Chapter 15: ADO Scripts for Rates.

Chapter 16: ADO Scripts for Posting.

Chapter 17: Output Data Structures.

Appendix A: InfoPath XSF Schema.

Appendix B: InfoPath Form Definition Reference.

Appendix C: InfoPath Object Model Reference.

Appendix D: References.



Read More Show Less

First Chapter

Professional InfoPath 2003

By Ian Williams Pierre Greborio

John Wiley & Sons

ISBN: 0-7645-5713-0

Chapter One

About InfoPath

In the spring and summer of 2002, Microsoft started showing pre-alpha versions of what was then called XDocs to selected corporate customers. Something interesting was on the way. XDocs was far from finished, and it wasn't certain how what is now InfoPath would be positioned or how it would fit into the rest of the Office product line. Some limited XML features were already present in the existing Office applications, and it was reasonable to expect enhancements in that area in the next major release. It was also clear, even then, that InfoPath was going to be something of a departure.

If InfoPath joined the Office application suite, it would be the only product without a considerable pre-XML legacy, and there was an opportunity to make a fresh start in introducing XML compatibility to part of the product line. It also seemed, as is still evident, that InfoPath would initially be much more dependent on developer skills than anything else in Microsoft Office 2003.

As time passed we learned that support for XML in the 2003 versions of Access, Excel, and Word would be expanded considerably from what was initially available in Office XP. The missing piece was the fit for InfoPath. In retrospect it seems obvious. InfoPath would be a new information-gathering program using XML as its native file format.

But why does Office need yet another XML processor? With the new features in Word, we can create custom XML documents. And Access 2003 and Excel 2003 will now do a good job of capturing regular data structures in any schema we choose. The answer lies in forms, possibly the last arena in office systems that is pretty much untouched by XML technology.

Initially, because of its inheritance from SGML, XML was seen as an enhancement that would benefit online document-oriented applications. Then XML was adopted, some think hijacked, by developers who wanted it as an interoperable format to oil the wheels of e-commerce, and there's no doubt that data-oriented XML has recently been the primary driver of Internet standards. Forms sit somewhere between the two poles of document and data orientation. Whereas documents can have extremely complex information structures, including features such as repeating elements and recursion, regular structures like database tables and spreadsheets are simple and straightforward. Office forms can combine the two features. They are usually quite short but often take a semistructured form, combining simple field lists with optional sections and repeating elements-for example, the dates and details in an expense claim.

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, however, 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

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 languages, 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.

Common Features in XML Forms

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.

A central design concept is a "package" of files with distinct functions: a template document with a structure definition from a fixed, industry-standard or custom XML schema; an XML file to contain default data; and form data in an XML file that can be routed to points in a workflow. At each point, the data is loaded into a form, which provides a view into editing all or parts of the form. This process can be repeated as many times as necessary, with any number of participants.

Some approaches, like XForms, use fixed element names for controls and encourage implementers to define the purpose of the data-gathering controls. This makes it easier to generate the related structures automatically, for example, creating different interface objects for PDA and desktop browsers. Others are more focused on providing a rich user interface (UI). However, most have a wide range of display properties that include showing or hiding parts of forms and repeating sections where elements can be added or removed by users.

Points of Difference

Probably the first distinction to note is between Web-based XML forms and rich client systems. Web-based applications have their attractions, and on office intranets they have become a common way to collect some kinds of information from employees. They are easy to deploy and inexpensive to support. But thus far they have not been good candidates for workflow processing. That will soon change as XForms-based tools appear.

Rich client applications are relatively expensive to deploy and maintain, but they are often more robust and can be more readily integrated with other desktop client systems. They can be operated when users are disconnected from the network, and there is some evidence that users prefer them to Web-based tools when they have a choice.

Another distinction is between declarative and scripting approaches. A goal of the XForms specification was to limit the need for scripting; it therefore makes use of XPath-based calculation and validation, and includes XML action elements that specify responses to events like setting focus or changing a data value. In contrast, InfoPath, although it makes some use of declarative programming, including XPath expressions, encourages the use of script more often.

InfoPath Features in Outline

Later in the book we'll discuss InfoPath features in greater detail, but for now, here's a summary of some of the key XML technologies and development approaches.

XML from the Ground Up

InfoPath applies a range of XML technologies recommended by W3C that we noted in the Introduction. This is a first for Microsoft, and thus a first for you as an Office developer. Additionally, InfoPath makes use of XML processing instructions and namespaces. There are also methods for accessing the XML document using the InfoPath Object Model (OM).

The following table outlines the use of some XML standards applied in InfoPath.

Some Constraints

Although InfoPath supports a wide range of XML features, there are some limitations or other constraints in this release that you should note. InfoPath 2003 does not support the following:

XML Schema constructs xs: any, xs: any Attribute

abstract and substitution Group attributes on elements and types

XSL Formatting Objects (XSL-FO) for the presentation of XML data

Import or inclusion of arbitrary XSL files

XML-Data Reduced (XDR) or Document Type Definition (DTD) for defining schemas

Digital signing of parts of a form

XML processor versions earlier than Microsoft XML Core Services (MSXML) 5.0

About Form Development

We've already noted a bit of a bias on the part of Microsoft toward code to extend the functionality of forms. This shouldn't be surprising, because Microsoft and therefore many developers of Microsoft applications have come to XML quite recently and have come from a code-based programming background. The structures found in XSLT, for example, can often seem obscure and foreign. As XML becomes a more prominent component in Office applications, we may come to see that declarative programming approaches are increasingly common.

When you modify InfoPath forms, by setting values in design mode or by editing values in the form files with a text editor, you are customizing the form declaratively. When you alter a form programmatically, you are writing code using JScript or VBScript following the InfoPath Object Model.

As we've mentioned already, there are often two or three ways to achieve the results that you want.

Declarative Development

Declarative development involves modifying one or more XML files, including:

XML Schema that defines the structure of the form

XSLT files that define the views on a form

XML form definition file or manifest that specifies the overall structure of a form

Why might you want to use the declarative approach? Well, one reason might be that you prefer it to programmatic development in certain cases, but there are times when InfoPath leaves you few options. Here are just some occasions when declarative programming is either recommended or necessary:

Custom form merging

New menus and toolbars

Schema and other upgrade modifications

Custom transform templates

Adding processing instructions to XML data files

Exporting form data to custom Excel schemas

Creating custom task panes and their associated files

Programmatic Development

You can customize a form programmatically by writing scripting code to perform a variety of functions. The main components that involve programmatic interaction are listed in the following table.

Microsoft Script Editor

InfoPath includes the Microsoft Script Editor IDE (Integrated Development Environment) creating and debugging code, together with programming languages that you can use to extend your applications. However, while other Office applications use Visual Basic for Applications (VBA) as their primary programming language, InfoPath uses two scripting languages-JScript and VBScript.

JScript is an interpreted, object-based language that is the Microsoft implementation of the ECMA 262 language specification. VBScript is a subset of the Microsoft Visual Basic. However, while you have a choice of languages, you cannot mix the two languages in a single form.

You can set the default language for a form in the design mode interface. When you open Microsoft Script Editor (MSE) from InfoPath in design mode, the MSE code editor appears and the form's default scripting file opens in the code editing window.

In debug mode, you can use all of the debugging features that MSE provides, including using breakpoints, stepping through program statements, and viewing any of the debugging windows.

Introducing the Design User Interface

InfoPath has separate modes for the two distinct tasks of filling out and designing forms. Design mode is the environment in which you create or modify a form template.

Before getting into the details of form architecture in the next chapter, we'd like you to take a quick look at the InfoPath user interface, with an emphasis on the design mode features. So if you haven't already done so, why not start InfoPath and take a short tour with us?

Start by opening the form template called Absence Request that comes with InfoPath. To open the form, click the More Forms button on the Fill Out a Form task pane, and choose the form on the Sample Forms tab of the dialog box. The usual path of the form template files is C:\Program Files\Microsoft Office\OFFICE11\1033\INFFORMS\1033\.

The workspace is divided into two main areas: the form area and the task pane area. The form area appears on the left side of the screen, and the task pane area by default appears on the right, regardless of whether you are designing a form or filling it out. Figure 1-1 shows the Absence Request form with the Help task pane.

The Form Area

The form area is where you enter your form data. When you fill out a form, the form template's location is displayed at the bottom left of the form area.

In design mode, a form appears in the same position, but you can access the form controls, set their properties, and define other form options. To switch between fill-out and design modes, you can either choose an option from the drop-down menu at the top of the task pane, click a toolbar button, or choose File[right arrow]Fill Out a Form or Design a Form. Figure 1-2 illustrates the form area in design mode.

The Task Pane Area

You can locate the task pane anywhere you like; it can be moved, resized, docked or floated, opened or closed, just like other Office applications.


Excerpted from Professional InfoPath 2003 by Ian Williams Pierre Greborio Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)