Architecture of the InfoPath Template (.XSN)

InfoPath templates use several child files and one overlying manifest bundled within an .XSN file.  However, there are both packaged and unpackaged InfoPath template states. One of the states is the form template, saved as the bundled .XSN file, which contains all InfoPath source files that although packaged can be extracted using either the InfoPath client or command line operations. Since an .XSN file is basically an archived cabinet file, you can unpackage an .XSN by using the following command; just replace the %system% placeholder with the system directory path and the %filename% placeholder with the path to the .CAB file:

%system%extrac32.exe /e /a %filename%
In order to repackage the extracted files into the .XSN cabinet, you can use the MAKECAB command form the command line as well. As a secondary option, to save the source files directly from the InfoPath client, you can simply use the Save Source Files option as opposed to saving the entire .XSN. There will be some file types that are not included in this breakdown, such as custom packaged .htm, JavaScript, VBScript, and compiled code files since they are unique to specific forms and are not universal across all .XSN’s.  By understanding the structure of what makes up an InfoPath form template, you can be more adequately prepared for programmatically manipulating form templates using programming approaches that provide more insight into the underlying plumbing of what builds the overall InfoPath template. Several ways to influence templates will be easily available which will allow you as a developer to develop scripting functions that you can optionally use in order to do actions such as bulk changes to XML attributes that make up the InfoPath file.
Manifest.XSF (Form Definition File
Manifest.XSF  is the overall manifest file, which although carries a unique file extension, is just a plain XML file. The most important function of the Manifest.XSFis providing the description of all the other child files that comprise the InfoPath template wrapped within the parent element, within  the child sub element. Each of the files that are included within the InfoPath form template are specified using the   element, which also further defines the properties of the files using. The manfiest.XSF also keeps other relevant global information regarding the template that can be modified by a developer such as menu items, along with some elements that are reserved by Microsoft, such as the element, and some elements that are typically not modified, such as the since InfoPath generated W3C.XSD schema document is typically used for traditional forms development.

During the course of creating a new custom form, you can modify some elements, although there are numerous elements that are not presented in the entire .XSF schema. The following table points out the relevant ones that appear within a default manifest.xml file when non-complex solutions are being used such as the case with the ID form being created, and some that you may typically manually modify.
Basic Elements of .XSF File


The view.xml file defines the available InfoPath views, back referenced by the manifest.XML in the element. The View files typically follow a numerically incremented pattern, where the first is view1.xml and the subsequent ones increase by an augmentation of one digit. The XSL will transform the selected XML input into an HTML view appending both the required CSS styles and the related InfoPath control values by using a xd:binding and xd:xctname attribute. The output when using the view.XSL file is a form that looks similar to how the InfoPath Form will be rendered and presented for web consumption.

Within the XSLT, the controls that are added to the template can be explicitly declared, by adding them within the XSLT file. Using the xd:binding attribute, InfoPath will take that element and push it to the XML source tree. Binding InfoPath controls such as the TextBox control will follow this schema.
The xd:binding attribute assimilates an XPath expression in order to bind the XML source tree, as shown in the my:pro2007Dev expression.
The xd:xctname attribute couples with the xd:binding attribute in order to define the type of control it is referencing. In the example code there is the reference to xd:xctname=”PlainText which means that the particular control is a TextBox InfoPath control.
The MySchema.XSD document controls the schema reference that is made from the manifest.XML declaration in the   element. This will default to the source files directory that the InfoPath solution file is unpackaged from. In the there are values which will classify the namespaces being used for the InfoPath solution package, and the rootSchema=”yes” attribute will by default  be set to the MySchema. The MySchema.XSD is based on the W3C XML Schema (WXS) which controls whether the InfoPath XML being passed in is valid or not. If the XML Schema file is not valid the form will be considered corrupt by the InfoPath Designer.

The sampledata.XML file specifies the default values that should be displayed to the user when first loading the InfoPath form. In the SampleData.XML file there is only the definition of the fields that are being used, their type, and the option to supply a default value by calling the element out by its name, along with specifying the value that should be set as the default. When you declare a new InfoPath control, it contains a self-terminating element at the top that you can set a default value for. To do so, simply state proSharePoint, which populates a TextBox control with string proSharePoint.
The template.XML file contains the XML information that is edited with InfoPath; however it’s only a sample illustration document provided within the overall InfoPath solution file. The template.XML provides an instance of the form will look to a user. The fields within the template.XML file are defined in the familiar my:field syntax.
There also is some interesting data that is included at the top of the document that related to problems that occur during the rendering of the InfoPath form. In the template.xml file there are the following header elements.
This section provides an important concept because it partially defines how InfoPath renders forms. By correlating an instance to a form, several form instances can be created out of a singular form template. The manifest location is kept in the href attribute, thereby allowing the template association over remote pipes so that a form template can be published to a collaborative location such as SharePoint and called be various segments. The element is known as the InfoPath Processing Instructions (PI’s), which is why there is a PIVersion numeric. The processing instructions define how to relate the data instances to the InfoPath form. If a form is not rendering correctly, InfoPath will look at the values as provided in the PI element in order to attempt to load the form within the InfoPath Smart Client.





Description of Element


Views that are available to the InfoPath Form. Any views placed within this element are the views used within the .XSN, pointing to the related View.XSL files. This and the are required elements in the .XSN without which the template is considered to be corrupted.
Form behavior when in InfoPath Design Mode and the application that was used in form creation. Can also house information that appears in design time in the InfoPath Smart Client.


Allows modification of the merge forms option, typically by using the useScriptHandler attribute to append event capturing.


Describes the overall update behavior if an antiquated forms requires increment to a new version.


Points to the template.xml included with the .XSN for when a user chooses to provide input to the form.


Provides the option of including packaged updates, such as forms services packs, for minor forms upgrades as they occur.