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.



Mastering InfoPath Development Series Introduction

Building business forms is an intrinsic part of architecting a serviceable collaboration environment that accentuates user interaction into overall business operations. Forms and the data that is entered into them build the backbone of most internal and external enterprise processes for organizations, regardless of industry background. One of the most frequent requests of any collaborative environment is to procure circumstances where normally endless paper, human-oriented processes are optimized and an environment that procures methodized, controlled, and manageable paper-less forms are introduced to speed user interaction, couple with intuitive workflows, fetch and push data between various types of data sources, and improve custom form time to production. The benefits of leveraging paperless forms are vast, ranging from cost benefits to flexible deployment and usability options. Form distribution fees and production costs are eliminated, capturing and routing become automated by the collaboration environment, forms can be audited for non-repudiation legal purposes, and robust levels of forms storage and pipeline security can be implemented.

InfoPath 2007 and Office SharePoint Server 2007 running InfoPath Forms Services, or a separately purchased Microsoft Office Forms Server (OFS 2007) platform, procure a bridge between the Information Worker whom is most aware of the organizational form content and process involvement, to the developer who can enhance and automate form activities, to the systems architect who is responsible for maintaining the form platform and tangible form maintenance.
Typical business form development can prove tend to be convoluted because a considerable quantity of conventional business forms are specialized in intent, often times the solitary persons whom are aware of how data should be inputted, manipulated, and stored is not an avid member of the development team. Empowering the set of stakeholders involved in the forms development process with the tools to help communicate needs to tangible deliverables, and deliverables to organizational systems will procure numerous benefits for an organization, increasing the overall quality and usability of the end product.
Stakeholders in the Form Development Process


Using Forms Services


For The Information Worker


Allow an integrated design environment where form controls can be easily added to a layout page, capturing the most beneficial user design while maintaining an uncomplicated, effortless form development and design surface.


For The Developer


Inherent functionality to bind form controls to various data sources and control basic form behavior. Allowance of backend managed code to tap into new InfoPath Object Model in order to create more complex form behavior using C# or VB.NET through the use of Microsoft Visual Studio Tools for Applications (VSTA) or Microsoft Visual Studio Tools for Office (VSTO). Support for native scripting languages such as Jscript and VBscript through the Microsoft Script Editor (MSE) for customizing other form attributes to be bundled with form template packages.


For the Systems Architect


Ease control over deploying custom forms to a SharePoint environment with a granular, defined publishing model. Exert forms jurisdiction over pieces that tap into custom business logic by allocating the task of activating such forms as an administrative task. Allow forms to be updated even while SharePoint users are entering in data, decreasing the amounts of service disruptions and increasing quality of data retrieval. Provide forms administration through familiar SharePoint STSADM command line interaction.


Throughout this series, I will introduce you to how to construct robust, extendable forms using InfoPath 2007. The constructed forms will then be able to employ InfoPath Forms Services in order to increase the reach of the form through its zero footprint form fill-in technology, allowing even users without the InfoPath Smart Client installed to utilize the InfoPath forms. As you’ll see shortly, you will exploit powerful development approaches that can immediately be put to work in your environment through the native InfoPath design surface and through custom managed code. The presented strategies include several sections of inherent InfoPath functionality as well as demonstrations of how to hook in custom logic written in managed C# code. For those developers who don’t have InfoPath 2007 as a development platform, for those developing forms solely on the Windows SharePoint Services V3 platform or not having the Enterprise Features of MOSS enabled, we will also explore how to use native WebPart development to build forms that can achieve the same goal as developing when using InfoPath 2007.
We will also walk through the architecture of InfoPath forms and InfoPath forms services. You will become familiar with the pieces that build up an InfoPath form and related pieces of technology that are important to an InfoPath forms developer. Since InfoPath FormsServices provides the foundational serving mechanism, we will also examine the core components that construct this service, and how exactly the rendering components of InfoPath Forms Services can expand the reach of custom built forms.
So warm up Visual Studio, strap on your seat belts, and let’s start developing!