Architecture of Microsoft Office InfoPath 2003

  • Article

 

Michael Hoffman
Microsoft Corporation

June 2003

Applies to:
   Microsoft® Office InfoPath™ 2003

Summary: Discover the architecture of Microsoft Office InfoPath 2003, including how InfoPath supports structural editing, several levels of validation, loading and submitting of XML documents, and multiple views of the DOM tree. (17 printed pages)

Contents

Input and Output of XML Documents
XML Authoring with Structural Editing and Validation
Flexible Views and XSLT
Designing a Form Template
Terminology
Summary

Microsoft® Office InfoPath™ is a new desktop application that enables teams and organizations to efficiently gather the information they need through rich, dynamic forms. This architecture includes distinctive design features that provide easy structured authoring and flexible viewing of XML documents. For a general overview of InfoPath, see the Technology Overview of Microsoft Office InfoPath 2003.

InfoPath has the following core design goals and main architectural features:

  • Build a hybrid tool combining the best of a document editing experience with the rigorous data-capture capabilities of forms. End users can see and modify abstract data structures using editing views in a traditional word-processing environment that provides familiar features such as rich text formatting, table and picture support, and AutoCorrect. The end user can dynamically extend a form, validly adding optional and repeating elements and attributes without seeing the elements and attributes.
  • For input and output, use XML documents belonging to a custom-defined schema. InfoPath enables ordinary end users to read and create semi-structured XML documents belonging to your custom-defined XML schema. Users can then submit data in XML format either through SOAP or through the HTTP POST method. InfoPath uses and produces XML schemas and XSL Transformation (XSLT) files, and is integrated with XML Web services standards.
  • Provide structural editing. InfoPath enables gathering structured, validated XML information that can be repurposed and connected to the overall enterprise, putting easy creation of XML content into the hands of ordinary end users. To present an easy user interface for visualizing and editing hierarchical XML data, nested field groups and fields in views are mapped to the Document Object Model (DOM) tree, and a context-sensitive drop-down menu in a view enables the end user to add or remove valid field groups. InfoPath supports custom-defined XML schemas, together with user interface customizations that comply with the schema. Industry-standard XML schema validation, additional custom declarative constraints, and support for script-based validation and business logic prevent data errors and ensure that the resulting XML documents fit your needs.
  • Provide flexible views. To present an XML document in a way that makes the most sense for the end user, InfoPath uses XSLTs to enable the content of the editing views to be organized differently than the structure of the XML data. InfoPath adheres to the XML paradigm of separating the data in a document from the formatting, enabling rigorous, structured data capture.

These architectural features are described in greater detail in the following sections.

Input and Output of XML Documents

InfoPath uses XML as its native data format for input and output. Support for custom-defined XML schemas enables opening and editing any XML documents used by XML Web services and XML-enabled systems. When editing an XML document, InfoPath enables you to add and remove valid XML elements and attributes belonging to your custom-defined XML schema. When you save or submit the XML document, the document remains valid following the XML schema.

Referencing and Updating the Form Template

A form template is a file or set of files that defines the data structure, appearance, and behavior of a form. InfoPath form templates include the following:

  • The XSLT files that define the views
  • One or more XML schemas
  • Scripting files for advanced custom validation
  • Any image files that are needed
  • A manifest file containing user interface customizations

When you receive and open an InfoPath form, InfoPath reads a processing instruction in the XML document to determine the location of the form template the XML document is based on. If this is the first time you have accessed the form template, it is downloaded to the local cache for form templates. If there is a locally cached copy of the form template and it is older than the copy on the server, the cached copy is updated from the server.

A form template can be stored as individual files within a normal folder. Or, for ease of deployment, these files can be stored in a cabinet file (.cab) that is renamed with an .xsn extension, making it easy to transport the files as a set.

A form template can be sandboxed or trusted. A sandboxed form template is cached for offline use, is automatically updated, and has restricted access to system resources. A trusted form template is manually installed and provides greater access to system resources.

Loading the XML Document into the DOM

When you open an existing XML document in InfoPath, an internal representation of the XML document is created in memory as a DOM tree. A transformed view of the DOM tree is displayed to the end user. The DOM tree is then used by other InfoPath features, including editing, validating, saving, and submitting an XML document.

Figure 1 shows how the DOM is used to load and store data for use by editing views.

Figure 1. How the DOM tree is used when opening and editing an XML document

Loading a Signed XML Document into the DOM

InfoPath supports XML documents that are signed using the World Wide Web Consortium (W3C) XML Digital Signatures standard. An InfoPath form can be signed using one or more XML digital signatures. The form is signed at the level of the entire XML document. A signed form is opened as read-only; InfoPath does not allow editing any data in the XML document, as long as it is signed.

When opening an XML document and loading it into the DOM, InfoPath checks whether it is digitally signed. If the XML document doesn't contain a signature, the form is immediately opened and presented to the user. If the XML document contains a signature, InfoPath decodes the document to see if it is consistent per the signature. If the XML document is valid per the signature, the form opens. If the XML document is not valid per the signature, a warning dialog box appears and the form is opened.

The digital signature resides in a node inside the XML document. When designing the form template, you specify which node the signature is stored in. The location of the signature node is stored as an XPath expression in the manifest file.

Loading an Initial XML Document from a Web Service

A form template can use a Web service operation to provide initial data for a form. For example, the end user could enter a sales employee's name into a text box in the initial view, and then retrieve initial data based on the entered name.

When an end user creates a new XML document based on a form template that uses a Web service operation to provide initial data, the default initial view is called the query view. When the user enters or selects some values in the query view and clicks the query button, values from the view are sent in a SOAP packet as input parameters to the Web service operation.

The Web service operation responds by returning a SOAP packet that contains the initial data as an XML fragment. The XML fragment conforms to the XML schema for the operation and is loaded into a DOM tree. The returned XML fragment is transformed using XSLT and presented to the user, showing the resulting initial data in the data entry view. The user can then edit the returned data and enter additional data.

Saving and Submitting XML Documents

You can save a form as a file, submit the form to a back-end system such as a Web service, or both. Because an InfoPath form template can be saved as a file, you could get an InfoPath form from a server, add to or edit the data, save the form and e-mail it to someone for review, and then submit the results to a server. This support for saving as well as submitting an XML document enables both centralized and peer-to-peer workflow, supporting various business scenarios.

The end user can sign an XML document before submitting it. When designing a form template, you can specify whether to allow the forms to be signed. You can also specify whether a dialog box will appear when the user submits the form, to prompt the user to sign the form, if the form lacks a signature. To sign a form, the user must have a certificate installed on his or her computer.

When you save an XML document, the DOM tree is read out and saved as an XML file. Similarly, when you submit an XML document, the DOM is read out and sent as an XML document. Only valid XML documents can be submitted; to submit an XML document, it must be fully valid, including the data types. You can submit an XML document to a Web service through SOAP, to a server through the HTTP POST method, or to a Web service or server using a custom script.

Submitting an XML Document to an XML Web Service

After filling out a form, the end user can submit the form data to an XML Web service. When the user submits the form, InfoPath wraps the resulting XML fragment in a SOAP envelope, as an input parameter for the Web service operation, and then sends the SOAP packet to the operation. The submitted XML document conforms to the schema for the operation.

To design a form template that submits an XML document to a Web service, you use the Data Source Setup Wizard to select which Web service to submit the XML document to, which Web service operation to use, and which XML fragment to send as the parameter for the operation. The XML fragment corresponds to a schema node and conforms to the XML schema for the operation. The definition of how the form submits an XML document to a Web service or HTTP server is stored in the manifest file.

Submitting an XML Document through HTTP

Alternately, InfoPath can submit an XML document to an HTTP server through HTTP using the POST method. When designing a form template, you add a Submit button in the view or enable the Submit command on the File menu, and specify a URL to use.

The URL can point to server code such as a CGI script that can process HTTP POST requests. When an end user submits a form based on the form template, InfoPath packages the XML document as the body of an HTTP POST request that is sent to the specified URL.

Submitting an XML Document Using a Custom Script

Using a custom script to submit an XML document provides the most control over how and where the data is to be submitted. You can use scripting to select what data you want to submit, and you can use any protocol or object that is available through script.

XML Authoring with Structural Editing and Validation

To enable ordinary end users to easily and validly add and remove XML subtrees, InfoPath provides the following structural editing features:

  • Use of nested groups of fields and user interface (UI) controls to represent an XML document
  • Use of an existing custom-defined XML schema and UI customizations to enable adding and removing XML subtrees
  • Data validation through an XML schema, custom validation rules, and scripting
  • Use of Extensible Hypertext Markup Language (XHTML) to create and store rich text

These structural editing components are described in the following sections.

Displaying Elements and Attributes as UI Controls

XML elements and attributes are mapped to fields in a view, such as text boxes and other UI controls. The fields can be grouped together into sections that can be nested. The XML document consists of a set of sections, which can be mandatory, optional, repeating, or repeating rows in a table. Users can insert multiple sections or rows when filling out the form.

Structural Editing to Add and Remove Subtrees

Structural editing in InfoPath provides an easy and natural user interface that enables ordinary end users to add and remove valid XML elements and attributes. Context-sensitive menus enable the user to add and remove field groups where valid, and you can design dynamic field groups in views using UI customizations that make the most sense for your end users. These structural editing features are described in this section.

Field groups are mapped to subtrees in the DOM. When the end user clicks a context-sensitive drop-down menu and adds a repeating or optional field group, such as a section or row, this adds a subtree to the appropriate node of the DOM, and thus adds a subtree of elements to the resulting XML document. Edits in the DOM tree include inserting an optional subtree, repeating a subtree, or replacing a subtree with another subtree (where the schema uses <xsd:choice>). Similarly, a field group in a view can contain other field groups and can be optional, repeating, or replaceable with another field group.

The XML schema, together with UI customizations, controls whether the Insert and Remove commands appear on the drop-down menu for a field group. If the schema allows adding nodes to a node of the DOM tree, the field group that is mapped to the node has a drop-down menu that enables the user to add a field group or field. When the user clicks this drop-down menu or right-clicks the field group and clicks Insert field group name, a subtree is added to the DOM.

Figure 2 shows the context-sensitive drop-down menu for a customer field group, enabling the user to add another customer field group, remove this customer field group, insert an item row in the table of purchase items in this field group, or insert an optional actions field group within this field group. The Click here icon provides another way to insert the actions field group. A shorter drop-down menu appears on each purchase-item row.

Figure 2. InfoPath user interface for structural editing

When designing a view to enable end users to add and remove field groups and fields, there are many different ways of presenting fields in field groups that comply with a given XML schema. User interface customizations provide flexibility in how the XML schema is represented to the end user, enabling you to provide the user interface that makes the most sense for your use of the schema. Information about UI customization is saved in a file called the manifest file, which is created by InfoPath when you design a form template.

For example, if the XML schema allows inserting optional elements in a specific subtree, when designing a view, you can decide whether to initially create the optional nodes in the DOM when the end user adds a field group that can contain the fields, and therefore whether to show the corresponding fields in the view. Suppose that in an existing XML schema from a Web service, the <Address> element contains optional <PoBox> and <ZipCode> elements as well as several required elements, as shown here:

<xsd:element name="Contact">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element ref="Name"/>
         <xsd:element ref="Address" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>
<xsd:element name="Name" type="xsd:string"/>
<xsd:element name="Address">
   <xsd:complexType>
      <xsd:sequence>
         <xsd:element ref="Street"/>
         <xsd:element ref="PoBox" minOccurs="0"/>
         <xsd:element ref="City"/>
         <xsd:element ref="State"/>
         <xsd:element ref="ZipCode" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>
</xsd:element>

When you design a view that uses this schema, you can choose whether or not to initially create the optional <PoBox> and <ZipCode> nodes in the DOM when the Address node is added during editing. This decision affects whether the PO Box and Zip Code fields are initially added in the view when the end user inserts the Address field group, as shown in Figures 3, 4, and 5. Either approach conforms to the XML schema.

Figure 3. Content of the view before inserting the Address node

Figure 4. Content of the view after inserting the Address node, if you decide to initially create the optional DOM nodes

Figure 5. Content of the view after inserting the Address node, if you decide not to initially create the optional DOM nodes

The following example shows the tagging that results in the manifest file if you decide to initially create the optional <PoBox> and <ZipCode> elements when the end user inserts an Address field group.

<xsf:view name="View 1" caption="Details">
   <xsf:mainpane transform="view1.xsl"/>
   <xsf:editing>
      <xsf:xmlToEdit name="Address_1" item="/Report/Contacts/Contact/Address" container="/Report/Contacts/Contact">
         <xsf:editWith caption="Address" component="xOptional">
            <xsf:fragmentToInsert>
               <xsf:chooseFragment>
                  <Address>
                     <Street></Street>
                     <PoBox></PoBox>
                     <City></City>
                     <State></State>
                     <ZipCode></ZipCode>
                  </Address>
               </xsf:chooseFragment>

A drop-down menu automatically becomes available when the end user selects a Contact field group, to enable the end user to validly insert the Address field group. The tagging in the manifest file implements this behavior as follows: The xOptional value of the component attribute on the <xsf:editWith> element indicates that the Address field group is to be treated as an optional section during editing. When the end user clicks in the view, InfoPath maps the user selection to the DOM, then evaluates whether the XPath of the user selection matches Report/Contacts/Contact/Address and whether the container of the user selection matches /Report/Contacts/Contact. If both conditions are met, the drop-down menu and the commands for inserting and removing the Address field group are available.

When the end user inserts an Address field group, the <Address> fragment specified in the manifest file is inserted in the DOM. The fragment shown in the preceding example contains the optional <PoBox> and <ZipCode> elements. In contrast, if you chose during design not to insert these optional elements when the user inserts an Address field group, these optional elements would be omitted from the fragment in the manifest file.

Information Stored in the Manifest File

The manifest file for a form template is named manifest.xsf. The main purpose of the manifest file is to store user interface customizations for structural editing. This structural editing information is the majority of the content in the manifest file. The manifest file also contains the following information:

  • The list of all files that constitute the form template, such as XML schema and XSLT files
  • Custom menus and buttons to add an appropriate user interface for the current editing view
  • Custom validation rules for any node of the XML document, using XPath
  • The URL or Web service location to submit the form to
  • A custom task pane that provides an additional user interface area to the right of the views

Levels of Validation when Updating the DOM during Editing

When editing an XML document, an end user performs actions such as entering values into fields, clicking a formatting control for rich text, selecting items from drop-down lists, and using context-sensitive drop-down menus to insert or remove field groups. These editing actions cause the DOM tree to be updated. For example, user editing actions may cause an attribute value to change in the DOM, or cause a subtree to be added to the DOM.

There are three successive levels of XML document validation, always starting with schema validation:

  • Schema-based validation. As the end user edits the XML document, the structure of the DOM tree is always kept valid according to the custom-defined XML schema.
  • Declarative validation rules using XPath.
  • Script-based validation.

If the user enters invalid data into a field that has multiple types of validation, schema-based validation errors appear first, followed by rule-based validation errors. You can control when script-based validation errors are shown.

A data validation error is indicated by a dashed red border around a field, a validation ScreenTip (called an inline alert), or a validation message dialog box (called a dialog box alert). You can override validation error messages to control what is displayed to the end user when an error occurs.

Schema-Based Validation while Updating the DOM during Editing

Validation against a custom-defined XML schema during editing helps users create structured XML data that is ready for reuse by systems that require schema-validated XML data. InfoPath interactively validates the XML document and prevents the user from submitting the form to a Web service or other data source in an invalid state.

When the end user edits the XML document, such as adding an optional or repeating field group, the data in the DOM is modified. Values for fields are stored in elements and attributes, and elements and attributes are added or removed from the DOM tree in a location that corresponds to the field or field group selected in the view. InfoPath redisplays the changed part of the view by applying the required part of the XSLT to the DOM.

As the end user edits an XML document, options are presented to ensure that the DOM structure is always valid. If the end user modifies a data type or value, if the attempted change is invalid, a dialog box alert appears or a dashed red border appears around the invalid value.

Declarative Validation Rules

When the end user edits an XML document, custom declarative validation rules can test for conditions in addition to the XML schema constraints. These declarative validation rules can test for conditions such as one field being greater than another. You can define custom validation rules for any node, using XPath.

For example, suppose that in the following sales report XML document, you want to require that a value in the price field must not be greater than the value in the maxPrice field:

<salesReport>
   <customers>
      <customer>
         <price></price>
      </customer>
      <sales>
         <maxPrice></maxPrice>
      </sales>
   </customers>
</salesReport>

To define this declarative validation on the price field, you select the price field in the view, then use the Data Validation dialog box to select the <maxPrice> schema node. The XPath expression for custom validation is then constructed automatically and transparently, and is stored in the manifest file as shown here:

<xsf:customValidation>
   <xsf:errorCondition match="/salesReport/customers" expressionContext="customer/price"
expression=". &gt; ../../sales/maxPrice">
      <xsf:errorMessage type="modeless" shortMessage="Price exceeds maximum"></xsf:errorMessage>
   </xsf:errorCondition>
</xsf:customValidation>

Script-Based Validation and Business Logic

By writing a script, you can define additional validation on the DOM tree or define other business logic, such as changing the values in the form and adding or removing field groups that conform to the XML schema.

To use scripting, you write event handler functions that are attached to events that are triggered by DOM changes. When any node of the DOM changes, a DATADom event occurs for that node, and triggers three editing events for the node: nodename::OnBeforeChange(), nodename::OnValidate(), and nodename::OnAfterChange(). You can invoke the script editor for a selected field within a view. The event and associated function stub are automatically created in the manifest file and script file, respectively.

To access the XML document through scripting, you use the familiar W3C DOM to access the data tree. The DOM provides a representation of the XML document and an object model that you can script to, using either Microsoft Visual Basic® Scripting Edition (VBScript) or Microsoft JScript®. For example, the following line of script sets the ZipCode attribute to "98102":

XDocument.DOM.documentElement.setAttribute("ZipCode", "98102")

In the following example, script-based validation could check whether a ZIP Code value is a legitimate ZIP Code from a list. The manifest file contains the <xsf:domEventHandler> element:

<xsf:domEventHandlers>
   <xsf:domEventHandler handlerObject="msoxd__ZipCode" match="/Report/Contacts/Contact/Address/ZipCode"/>
</xsf:domEventHandlers>

The script file contains the associated function:

function msoxd__ZipCode::OnBeforeChange(eventObj)
{
   // Code for the event handler function
}

Authoring Rich Text as XHTML

End users can add formatted text such as detailed notes to an XML document using a rich text box. When the user selects a rich text box, the related editing features in the user interface become available, allowing the entry of rich data such as font formatting, bulleted lists, hyperlinks, tables, and images. The data entered into the rich text box is stored as XML elements that import the xhtml namespace.

To enable a node in an XML document to contain XHTML content, its schema definition must import the xhtml namespace. The document node can then be bound to a rich text box, which enables the user to edit the XHTML content.

For example, the following XML document fragment shows how a Notes rich text box containing a numbered list is stored:

<notes>
   <ol xmlns="http://www.w3.org/1999/xhtml">
      <li>Identify and check with the primary contacts.</li>
      <li>Schedule Paul to detail the issues.</li>
   </ol>
</notes>

In the XML schema for this example, the <notes> element is of type xhtml, and can contain any elements that import the xhtml namespace.

Flexible Views and XSLT

To support rich views with dynamic, flexible presentation of content, InfoPath uses XSLT transformations. The use of XSLT supports a flexible mapping between the grouped UI controls in the views and the nodes in the DOM tree. A view is an XSLT-based view of the DOM tree; when an end user opens a form, XSLTs are applied to the DOM tree to produce a view. If the user selects a different view from the View menu, a new transformation is run against the DOM, showing a different set of nested field groups.

A form can include multiple views, such as overview and detailed views. A view consists of nested sections that contain text fields and other UI controls. Each view produced by InfoPath is stored as a separate, standard XSLT file that can be reused by other business processes. When you add a new view in a form template, InfoPath creates the view by adding tagging to the manifest file and by creating an XSLT file for the new view.

You can easily design XSLT views for editing XML documents. InfoPath automatically generates the XSLT code that maps between complex XML data structure and useful views of that data. When you drag and drop UI controls onto the form area, InfoPath suggests appropriate transformations between the data structure and the views. This helps prevent XML transformation from being a difficult hurdle when implementing forms.

You can organize the content of the views very differently than the structure of the XML document, to present the data in a way that makes the most sense for the user. You can display data in a different sequence than in the DOM tree, omit some data from a view, reorganize adjacent data tree nodes into separate views, and gather data from different parts of the data tree into a single view.

How Multiple Views Are Stored in the Manifest File

The list of views for a form template is stored in the manifest file, together with context-sensitive custom additions to toolbars and menus, as follows:

<xsf:views default="View 1">
   <xsf:view name="Detail View">
      <xsf:mainpane transform="view1.xsl"/>
      <xsf:editing>...</xsf:editing>
      <xsf:menuArea>...</xsf:menuArea>
   </xsf:view>
   <xsf:view name="Summary View">
      <xsf:mainpane transform="summary.xsl"/>
      <xsf:editing>...</xsf:editing>
      <xsf:menuArea>...</xsf:menuArea>
   </xsf:view>
</xsf:views>

The <xsf:mainpane> element for each view defines which XSLT file to use for the view. The <xsf:editing> element defines the user interface customizations for structural editing in the view. The <xsf:menuArea> element defines additional menus and buttons to add to the toolbar for the view.

Incremental Transformation

To avoid running the entire XSLT every time the end user enters data in a view or clicks a formatting control for rich text, algorithms are used to determine which portion of the view needs to be refreshed. After an edit, only the relevant portion of the XSLT stylesheet is applied to the DOM, and the affected portion of the view is refreshed.

How CSS Is Used for XSLT-based Views of the DOM

When you design a form template, cascading style sheets (CSS) tagging is used in conjunction with XSLT to describe the formatting of the nested field groups and fields in the views. To display and format a view, the XSLT file produces XHTML output that includes and references the CSS <style> element.

For example, if you change the color scheme of a view, the CSS tagging in the XSLT file changes accordingly. When you select the "Blue" color scheme in the Color Schemes task pane, the XSLT file for the view includes the following tagging in the <style> element:

H1 {
   MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; COLOR: #1e3c7b
}
.accentDark {
   COLOR: white; BACKGROUND-COLOR: #517dbf
}
.accentLight {
   COLOR: black; BACKGROUND-COLOR: #ebf0f9
}

If you change the color scheme to "Red," the color values in the XSLT file change accordingly.

Designing a Form Template

InfoPath supports designing a form template using several different approaches:

  • By using an existing XML schema
  • By generating an XML schema from an XML document
  • By defining an XML schema from scratch
  • By using an existing XML schema from a Web service

These approaches are described in the following sections.

Designing a Form Template Using an Existing XML Schema

You can start designing a form template by using the Data Source Setup Wizard to load a custom-defined XML schema that has already been created by a tool that follows the XML Schema standard. The XML schema is shown as a tree control in the Data Source task pane.

The layout tools in the task pane enable you to lay out sections, such as rows and the background design, in one or more views. When you drag and drop a schema node onto the form area, an appropriate UI control is automatically suggested. For example, if the XML data type is date, InfoPath suggests a date picker control. If a schema element is optional or repeating, you can insert an optional field group or a repeating field group in the view.

Mapping the XML schema elements to the UI controls generates the XSLT tagging for the current view. The XML schema and the XSLT file for the view are automatically associated with the form template.

Designing a Form Template without an Existing Schema

If you select a well-formed XML document as the data source, InfoPath generates an XML schema that describes the XML document. You can then lay out field groups in the views to create a form template based on the generated schema.

Or, when designing a form template from scratch, you can use InfoPath to manually define a schema while you are laying out the field groups in the views. When you map a UI control to a node of a schema you are designing, InfoPath automatically suggests an appropriate data type for the schema node. InfoPath generates simple, standard XML schemas that can be used by other business processes.

Designing a Form Template Based on a Web Service

The Data Source Setup Wizard enables you to design a form template by starting with an XML schema that is read from the WSDL information of an XML Web service. When an end user creates a form based on the form template, the form generates schema-valid SOAP messages. As a high-level authoring tool for XML documents, InfoPath supports the document/literal SOAP encoding rather than Remote Procedure Call (RPC) SOAP encoding.

The Data Source Setup Wizard enables you to specify the location of the Web services to use, either by searching a Universal Description, Discovery, and Integration (UDDI) registry to find each WSDL file location, or by directly typing the Web Services Description Language (WSDL) locations, such as https://www.contoso.com/Service.asmx?WSDL.

The Search Web Service dialog box, shown in Figure 6, enables you to search a specified UDDI Web services registry to locate available XML Web services. You specify the URL of a UDDI server, such as http://uddi.microsoft.com/inquire, or any other server that uses UDDI 1.0 on any platform. You can search by the service provider description or by the Web service description. A UDDI request is then automatically built by InfoPath and sent to the UDDI server, which returns a list of matching Web services to select from, shown in the format Service provider::Web service name.

Figure 6. The Search Web Service dialog box

You can design a form that can retrieve initial data from a Web service, submit an XML document to a Web service, or both. The Data Source Setup Wizard enables you to specify how the form calls the Web service operations that are used to retrieve initial data and submit an XML document. InfoPath reads the description of a Web service from the WSDL file, which defines what operations are provided by a Web service and what parameters are used by each operation. The wizard then enables you to select which operation of each Web service to use.

Using WSDL, InfoPath extracts the XML schema that is associated with the selected Web service operation, and uses that schema as the data source for the form template. You can select which schema node is associated with a parameter of an operation, to provide the data for the parameter. In some cases, InfoPath prompts you for sample values and uses the values to automatically call the selected operation and design the data structure from the output received.

When you have selected the Web services, operations, and schema nodes for parameters in the wizard, InfoPath automatically creates an empty query view and data entry view. The Data Source task pane shows the schema subtree for each Web service operation, including the XML structure for retrieving initial data and the XML structure for submitting an XML document.

Terminology

field group: A section, repeating section, optional section, or repeating table. Sections and repeating tables are controls on a form that contain other controls and that can be added dynamically by users as needed. Users can insert multiple sections or rows when filling out the form.

DOM tree: The structure of the data source of the form. In particular, the collection of fields and groups that define and store the data for an InfoPath form.

Summary

InfoPath natively uses XML standards for input and output and enables ordinary end users to view and create semi-structured XML documents belonging to a custom-defined XML schema. InfoPath uses and produces XML schemas and XSLT files, and is integrated with XML Web services standards. Data can be submitted in XML format through SOAP or through the HTTP POST method.

Flexible structural editing enables the user to expand the XML document by validly adding optional and repeating elements. InfoPath uses your existing custom-defined XML schema to constrain and guide editing. When designing a form template, you can fine-tune the user interface, such as controlling which optional nodes are added to the DOM when a user adds a field group. XML schema validation ensures that valid XML is produced, and you can define additional declarative constraints and scripting for custom validation.

To enable rigorous data capture that is optimized for end users, InfoPath provides flexible views of the abstract data structures of XML. This approach uses the XML paradigm of separating the data in a document from the formatting. These flexible views are based on XSLTs, which enable the content of the editing views to be organized differently than the structure of the XML document. Views show the XML document as nested field groups containing text fields and other UI controls. Elements and attributes of the DOM tree are mapped through XSLT to the field groups and fields.

InfoPath is a hybrid tool that combines the best of a traditional document editing experience, such as a word processor, with the rigorous data-capture capabilities of forms. InfoPath makes it easy to design and edit semi-structured documents that have regions of meaning, in the same way that columns in a database have meaning. This design architecture provides a new hybrid tool that enables you to easily gather information that was previously more difficult to capture, such as business-critical data contained in sales reports, inventory updates, project memos, travel itineraries, and performance reviews.