Extending Forms

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This topic provides an overview of the ways in which the Form content type in Windows SharePoint Services 3.0 can be extended.

Third-party developers can create a DLL that provides a launcher control for opening the XML files of a Form content type in an XML editor that is compatible with Windows SharePoint Services.

The Form content type is an extension of the Document content type and is designed for XML files. In Windows SharePoint Services 2.0, the special functionality offered by forms was tied to the form library template. In Windows SharePoint Services 3.0, this special form functionality is encapsulated in the Form content type, and content types derived from it. This frees users from the previous restriction of having to store their forms in a separate library from documents, and being able to store only a single type of form in each form library. Now, not only can you store multiple types of forms in a single library, you can store both forms and documents in the same library.

The Form content type provides the following functionality for working with XML files:

  • Property Promotion and Demotion   Promotes data stored in the XML file as columns in the SharePoint library, and allows writing back to the document through those properties.

  • Link Management   Keeps links in the XML files associated with the template of the form.

  • Merge Forms   Sends multiple XML files to a client application to be merged.

Creating and Registering a Launcher Control

Third-party developers can create a DLL that provides the launcher control for opening XML documents in an XML editor. The control must provide the same interface for creating, editing, and merging XML files, as well as for customizing templates, as described for the OpenXMLDocuments Control control. The control must have a ProgID, such as SharePoint.OpenXMLDocuments, and be installed and registered on the client computer.

The DocIcon.xml file for a Windows SharePoint Services deployment can be customized so that the ProgID (for example, Word.Document) and the file name extension of a specific document type map to the ProgID of the launcher control and to an icon for representing documents in the form library.

Property Promotion and Demotion

Windows SharePoint Services 3.0 provides both document property promotion and demotion for XML forms.

Windows SharePoint Services includes a built-in XML document parser you can use to promote and demote the properties included in your XML documents. Because forms are XML documents, Windows SharePoint Services automatically invokes the built-in XML parser whenever document property promotion or demotion is required.


Property promotion refers to extracting values from a form, and writing those values to the appropriate columns on the library where the form is stored. Property demotion refers to taking column values from the library where a form is stored, and writing those column values into the document.

For more information, see XML Document Property Promotion and Demotion.

Link management allows you to keep the forms assigned on a given form content type synchronized with the form content type template. The mechanisms for link management include the following:

  • Automatic link management    After a form is synchronized with the template, if any site, subsite, or library is renamed, the link is kept synchronized automatically with the template URL of the form content type.


    Link management does not occur right away. A flag is set and it occurs when the file is requested for download.

  • Manual relink   If the form is initially out of synch with the template URL of the form content type, selecting Relink forms to this form content type on the Customize page allows a manual relinking. This is used for uploaded documents, or for forms copied from one server to another.

Both mechanisms require that the TemplateUrl column in the Form content type specify the location in the XML form where the form template is specified. This enables Windows SharePoint Services to demote the correct template location into the XML documents assigned to this content type.

If this information is stored in a process instruction in the XML form, use the PITarget and PIAttribute attributes in the TemplateUrl column definition to specify its location, as shown in the following example.


In addition, you can specify a primary location in a processing instruction where Windows SharePoint Services 3.0 should look first, before looking in the location specified by the PITarget and PIAttribute attributes. To do this, you add another pair of attributes: PrimaryPITarget and PrimaryPIAttribute. If these attributes are present, Windows SharePoint Services 3.0 looks for the template URL in the location they specify first. If there is a value at that location, the parser uses that value and ignores the PITarget and PIAttribute attributes, as shown in the following example.


If this information is stored in the XML content of the form, use the Node attribute in the TemplateUrl column definition to specify its location, as shown in the following example.


For more information about how Windows SharePoint Services 3.0 uses these attributes to promote and demote document properties such as the template URL, see Using Content Types to Specify XML Document Properties.

Merge Forms

Merge forms provides the Form content type with a mechanism for providing a combined view of forms that have the same schema.

For merging to be enabled for a content type, that content type must contain the Merge site column, with an internal name of "Combine." By default, the Form content type includes the Merge site column with the appropriate internal name. The Merge column enables users to select which forms they want to merge.

See Also


XML Document Property Promotion and Demotion