XForms and Microsoft InfoPath

by Micah Dubinko
October 29, 2003

Micah Dubinko is author of XForms Essentials.

"Do not go where the path may lead; go instead where there is no path and leave a trail." -- Ralph Waldo Emerson

This month Microsoft is releasing Microsoft Office InfoPath 2003, putting an end to speculation about what the software giant's approach to XML data collection would be. InfoPath appears on the surface to be similar in functionality to several of the XForms engines I wrote about earlier. Although the official Microsoft FAQ no longer even mentions XForms as of this writing, InfoPath is frequently compared and contrasted with XForms.

To be more precise: InfoPath is an application and XForms is a data format, so they can't directly be compared. It is possible, on the other hand, to compare the data format and processing model underlying InfoPath with XForms, which is the approach this article takes.

Related Reading XForms Essentials By Micah Dubinko Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

How Does It Work?

The InfoPath application, much like an XForms engine, converts user input into new or modified XML, which can then be fed into a back-end system. A single Windows-based application is used for both designing and completing a form.

An InfoPath document is stored and processed as several files, which can be either combined into a single CAB-compressed file with a file extension of .xsn or stored in the same directory. Either way, there are several key components.

manifest.xsf

This file contains a manifest, a listing of all other files in the bundle, called a solution. InfoPath keeps several other details here as well, including metadata, information on toolbars and menus associated with each view, information on external data sources, and error messages.

This file is roughly analogous to an XForms Model in that it contains the central hub a form.

view1.xsl, view2.xsl, view3.xsl, ...

One or more sequentially-numbered XSLT files are always included, each one defining an InfoPath view, which presents an editable view of a portion of the XML data under consideration. Each XSLT accepts the XML instance as input and produces an output format similar to HTML forms, but augmented with several InfoPath-specific features.

This XSLT transformation doesn't have an equivalent in XForms, but the HTML-like format produced by the transformation is conceptually similar to the XForms User Interface specification.

template.xml

This file contains the actual XML data that is edited by InfoPath. When the overall InfoPath form is published to a well-known location, the XML instance can be separately transported, via email or any other supported path. A special pair of processing instructions included in this file help maintain the connection between the form data and the rest of the form:

<?mso-infoPathSolution solutionVersion="1.0.0.1" href="manifest.xsf"
   productVersion="11.0.5531" PIVersion="1.0.0.0" ?>
<?mso-application progid="InfoPath.Document"?>

When Internet Explorer encounters any XML document with these processing instructions, it attempts to launch the locally installed InfoPath application, pointing it to the indicated manifest file. Unfortunately, this technique is specific to IE and will not work with other browsers.

myschema.xsd

InfoPath is strongly based on W3C XML Schema (WXS), and the application maintains a WXS instance for the main XML data. InfoPath will refuse to open a form if the template XML is not valid according to the specified schema. A graphical Data Source view in InfoPath, while not a full-fledged editor, allows the designer to make changes to the WXS.

script.js

InfoPath also includes extensive scripting capabilities, in either JScript or VBScript. If an InfoPath document contains any script, it is stored by default in this file.

It's possible for the InfoPath document to contain other user-inserted files as well, including images, XML that can be used as an alternative data source, and even HTML files that can be displayed in a special area called the Task Pane.

Similar, Different

How comparable is InfoPath to XForms? At a high level, both seek to overcome a similar challenge: translating user interaction into XML. Upon closer examination, however, the two technologies differ in focus, target audience, and scope.

Focus

The InfoPath application is focused on providing a superb visual environment, of similar quality to the rest of the Microsoft Office System suite, for creating and filling out forms. In contrast, the XForms specification is designed to encourage implementations not to focus exclusively on visual media, but rather to define only the intent behind various data-gathering controls. The XForms specification gives implementations wide latitude in choices relating to how a particular form control can be implemented, though new CSS properties can narrow down the specific appearance of a form control. Additionally, while XForms is designed to be readily produced by automated tools, InfoPath appears to be put together in such a way that only mouse-designed forms are readily possible.

Target Audience

The recommended system requirements for InfoPath demand a fairly modern Intel-compatible computer: a Pentium III or better as well as Microsoft Windows 2000 (with Service Pack 3) or greater. Further, the software is bundled only in the Enterprise version of Office System, which will in practice be most often used by larger, more Microsoft-committed organizations. By contrast, the XForms specification was designed to work on the broadest possible range of devices, from tiny phones and PDAs to beefy servers. XForms software is being made available in a variety of packages, both open source and commercial, on an assortment of platforms.

Scope

XForms encourages development using a defined declarative XML syntax, while InfoPath, like HTML forms, continues to encourage the deployment of script. Some interesting differences are also found in the choices of form controls supported. For example, InfoPath includes ordered and unordered lists as a form control, but doesn't support the equivalent of a multiple selection or free entry select form control (combobox).

A Word on Standards

InfoPath is built upon an impressive list of standard technologies, including WXS, DOM, and XSLT. For web developers modifying existing InfoPath content, such a design can be of great assistance. Other design decisions in InfoPath, however, tend to reduce the ability to use InfoPath with non-Microsoft browsers, platforms, or servers. For example, any investment in designing InfoPath solutions can be difficult to recoup in the face of changing to a different set of tools, no matter how standards-compliant they are.

A Real-World Example

Despite the differences, comparisons between XForms and InfoPath have been inevitable. A chapter in XForms Essentials examines a UBL purchase order application. It is possible to recreate that application in InfoPath and thus compare the results. Doing so is largely a hand-to-mouse experience with the InfoPath application. The result is shown in Figure 1.

The design view of Microsoft InfoPath (click for larger image)

Limitations in InfoPath made a few changes necessary—for example, there is no match for the range control for a volume-control slider—but overall the solution ended up quite similar to that of XForms.

One notable difference, however, is that tables, which can be seen here as dotted lines, are required for any kind of layout, which might make things more challenging for non-visual users.

The other major difference was the lack of declarative elements. In XForms, the bind element establishes a relationship that the XForms Processor sticks to at all times; for example, that the currency type entered once gets copied to all of the line items. In InfoPath, script attached to a number of different entry points is required. To conform to the rules of UBL with this simple interface, the purchase order application had four assertions to maintain:

1. A single currency code is copied into each repeating line item.
2. Since the currency code appears in two places in each line item, it is also copied to the second location.
3. For each line item, the extended price is calculated as price times quantity.
4. The total of the extended price across all line items is summed up.

In XForms, these four assertions are accomplished through four XML elements, each of which contains a desired condition to be met:

<xforms:bind nodeset="cat:OrderLine/cat:LineExtensionAmount/@currencyID"
     calculate="../../cat:LineExtensionTotalAmount/@currencyID"/>
<xforms:bind nodeset="cat:OrderLine/cat:Item/cat:BasePrice/cat:PriceAmount/@currencyID"
     calculate="../../../../cat:LineExtensionTotalAmount/@currencyID"/>
<xforms:bind nodeset="cat:OrderLine/cat:LineExtensionAmount" 
     type="xs:decimal"
     calculate="../cat:Quantity * ../cat:Item/cat:BasePrice/cat:PriceAmount"/>
<xforms:bind nodeset="cat:LineExtensionTotalAmount" type="xs:decimal"
     calculate="sum(../cat:OrderLine/cat:LineExtensionAmount)"/>

In InfoPath, however, the needed script is approximately 70 lines:

XDocument.DOM.setProperty("SelectionNamespaces",
    'xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70"
    xmlns:ns1="urn:oasis:names:tc:ubl:Order:1.0:0.70"
    xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2003-04-19T20:40:35"');

function XDocument::OnLoad(eventObj) {
  updateCurrency();
}

// This function is associated with: 
// /ns1:Order/cat:OrderLine/cat:Quantity
function msoxd_cat_Quantity::OnAfterChange(eventObj) {
  recalcLineItem(eventObj.Site.parentNode);
  recalcTotal();
}

// This function is associated with: 
// /ns1:Order/cat:OrderLine/cat:Item/cat:BasePrice/cat:PriceAmount
function msoxd_cat_PriceAmount::OnAfterChange(eventObj) {
  recalcLineItem(eventObj.Site.parentNode.parentNode.parentNode);
  recalcTotal();
}

// This function is associated with: /ns1:Order/cat:LineExtensionTotalAmount/@currencyID
function msoxd__LineExtensionTotalAmount_currencyID_attr::OnAfterChange(eventObj) {
  updateCurrency();
}

function recalcLineItem( lineNode ) {
  var quantity = lineNode.selectSingleNode("cat:Quantity");
  var price = lineNode.selectSingleNode("cat:Item/cat:BasePrice/cat:PriceAmount");
  var extended = lineNode.selectSingleNode("cat:LineExtensionAmount");
  var extPrice = parseFloat(getElementValue(quantity)) * parseFloat(getElementValue(price));

  setElementValue(extended , floatToString(extPrice, 2));
}

function recalcTotal() {
  var dom = XDocument.DOM;
  var extended = dom.selectSingleNode("/ns1:Order/cat:LineExtensionTotalAmount");
  var newTotal = sum("/ns1:Order/cat:OrderLine/cat:LineExtensionAmount");
   setElementValue( extended, newTotal );
}

function updateCurrency() {
  var dom = XDocument.DOM;
  var copyFrom = dom.selectSingleNode("/ns1:Order/cat:LineExtensionTotalAmount/@currencyID");
  var lines = dom.selectNodes("/ns1:Order/cat:OrderLine");

  // loop through each line item, copying in the currencyID
  for (var idx=0; idx<lines.length; idx++) {
    var copyTo = lines[idx].selectSingleNode("cat:LineExtensionAmount/@currencyID");
    copyTo.nodeValue = copyFrom.nodeValue;
    copyTo = lines[idx].selectSingleNode("cat:Item/cat:BasePrice/cat:PriceAmount/@currencyID");
    copyTo.nodeValue = copyFrom.nodeValue;
  }
}

// Utility functions

function getElementValue( node ) {
  if (node.firstChild)
    return node.firstChild.nodeValue;
  else
    return "";
}

function setElementValue( node, newval ) {
  if (node.firstChild) {
    node.firstChild.nodeValue = newval;
  } else {
    var textnode = node.ownerDocument.createTextNode( newval );
    node.appendChild( textnode );
  }
}

function sum(xpath) {
  var nodes = XDocument.DOM.selectNodes(xpath);
  var total = 0;
  for (var idx=0; idx<nodes.length; idx++) {
    total = total + parseFloat(getElementValue(nodes[idx]));
  }
  return total;
}

function floatToString(value)
{
  return "" + value;
}

This script approach requires a bit of care in getting and setting values from XML elements. In accordance with the DOM worldview, actual data values are stored in a text node child of the element node, except that an empty value is signified by the lack of any text child node.

On my initial attempt at this script, I neglected to attach an OnLoad entry point. The solution seemed to work, but had a subtle bug: if the initial value in the currency selection list was never changed, the currency value never got propagated throughout the XML. One advantage of a declarative approach is that it applies equally to initial conditions as well as the ongoing state. The XForms example didn't have to be special-cased for initialization.

Though not used here, the extensive sample forms that come with InfoPath include a large library of script that can be reused via copy-and-paste. The resulting InfoPath document can be filled out in the same application that designed the form, as shown in figure 2.

The data entry view of Microsoft InfoPath (click for larger image)

Conclusion

Both InfoPath and XForms are version 1.0 efforts, and both are likely to improve substantially in future revisions. For organizations that have already licensed Office System 2003, InfoPath will provide an excellent means to automate data collection tasks. For use on systems not running Office System 2003, including Mac and Linux desktops, phones, PDAs, and even some PCs, XForms remains a better path.

Resources

• Microsoft InfoPath SDK
• Official Microsoft InfoPath FAQ
• Unofficial InfoPath FAQ maintained by Stephen Cummins and Richard Fitzpatrick
• O'Reilly XForms Essentials, published online under the GFDL.

---

Share your questions or comments on this article in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article

---

Titles Only

Titles Only

Newest First

• InfoPath is built...
  2004-11-02 01:00:46 niq [Reply]
  
  InfoPath is built upon an impressive list of standard technologies, including WXS, DOM, and XSLT. For web developers modifying existing InfoPath content, such a design can be of great assistance. Other design decisions in InfoPath, however, tend to reduce the ability to use InfoPath with non-Microsoft browsers, platforms, or servers. For example, any investment in designing InfoPath solutions can be difficult to recoup in the face of changing to a different set of tools or ebooks, no matter how standards-compliant they are.
  
  

• Question
  2004-03-22 21:19:46 Louis McDavid [Reply]
  
  Great Information. I appreciate the discourse on InfoPath as my company attempts to make use of it.

  
  Does this error message mean anything to you?

  
  Form template: C:\Documents and Settings\Louis C McDavid III\Desktop\Property.Boiler Proposal 3.22.04.xsn
  The form definition (.xsf) file cannot be opened because of an error.
  The file cannot be validated by the XML Schema.
  Element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}header' is unexpected according to content model of parent element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}printSettings'.
  Line 367, Position 17
  <xsf:header>

  
  
  Kind regards,

  
  Louis
  
  

  • Question
    2008-01-30 20:42:12 GopiGrut [Reply]
    
    PROBLEM DESCRIPTION
    ==================
    A view in an InfoPath form template has a print footer. That form template is opened and a print header is added to the view. Once the form template is saved and closed, it cannot be reopened. InfoPath displays an error:

    
    ERROR
    =======
    InfoPath cannot open the form.
    The form definition (.xsf) file contains errors.

    
    The form definition (.xsf) file contains elements, attributes, or structures that are not valid.

    
    Error details:
    Element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}header' is unexpected according to content model of parent element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}printSettings'.

    
    Line 145, Position 17
    <xsf:header>
    ----------------^

    
    O: (Objective)
    ENVIRONMENT
    ===========
    Microsoft Office InfoPath 2003 Sp2

    
    A: (Assessment)
    RESOLUTION
    =============
    Unfortunately, this problem is a known bug introduced by a regression in SP1 for InfoPath 2003. In the InfoPath form template’s manifest.xsf file, the “xsf:printSettings” node contains the print settings for a view in the form template. Included in this node are (optionally) an “xsf:header” and “xsf:footer” node which contain the header and footer information for the view, respectively. The “xsf:header” node, if present, must come before the “xsf:footer” node, if present. When the problem occurs, these two nodes have gotten reversed, so the “xsf:header” node follows the “xsf:footer” node. This violates the schema for the manifest file, so InfoPath cannot open the form template.

    
    This problem was detected and corrected in Microsoft Office InfoPath 2007.

    
    To ensure that the problem does not occur, be sure to add the print header for a view before adding the print footer. This ensures the proper order of the nodes in the form’s manifest file. Note that once the footer node has been added to the manifest, it is not removed, so it is not sufficient to remove the footer from the form before adding a header.

    
    If a form template view already has a footer, or if an existing form template has already become corrupted by this problem, it will be necessary to edit the form template manifest manually to correct the problem. An InfoPath form template (.XSN) is just a special CAB file, and it can be opened and extracted using common tools like WinZip. Therefore, use these steps to correct the problem in an existing form:

    
    1) Make a backup copy of the form template just in case you make a mistake editing the form template so you don’t lose your work.
    2) Open the form template in WinZip and extract all the files into a folder.
    3) Open the “manifest.xsf” file in a text editor like Notepad. (In very rare cases, the file may not be named “manifest.xsf”, but it will have a “.xsf” file extension. There will only be one such file in a form template.)
    4) Find the “xsf:printSettings” node in the manifest file.
    a. To remove an existing footer so a header can be added, delete the “xsf:footer” node (everything from <xsf:footer> to </xsf:footer> inclusive) inside the “xsf:printSettings” node.
    b. To repair existing corruption, move the “xsf:header” node (everything from <xsf:header> to </xsf:header> inclusive) inside the “xsf:printSettings” node so that it comes immediately before the “xsf:footer” node (everything from <xsf:footer> to </xsf:footer> inclusive).
    
    

  • Question
    2008-01-20 01:03:40 GopiGrut [Reply]
    
    How do I fix this?:

    
    Form template: C:\Documents and Settings\DWetherow\Desktop\IEP Current Draft Jan 20 2008.xsn
    The form definition (.xsf) file cannot be opened because of an error.
    The file cannot be validated by the XML Schema.

    
    Element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}header' is unexpected according to content model of parent element '{http://schemas.microsoft.com/office/infopath/2003/solutionDefinition}printSettings'.

    
    Line 177, Position 17
    <xsf:header>
    
    

• Some other good InfoPath articles
  2003-10-30 22:18:08 Mark J [Reply]
  
  I enjoyed this article! Some other good InfoPath articles:

  
  http://www.PerfectXML.com/InfoPath.asp
  http://www.PerfectXML.com/InfoPathOracle.asp
  
  

• security?
  2003-10-30 03:31:03 bryan rasmussen [Reply]
  
  "Unfortunately, this technique is specific to IE and will not work with other browsers"

  
  concerning those two processing instructions (haven't tried the infopath we have here yet) couldn't there be some security holes in there somewhere?

  
  so which version of IE does infopath require? and are there other processing instructions that will cause it to do stuff, beside the standard xsl stylesheet one.