XSD has become a core part of many of the customers that I work with. Within these customers they are using XSD as a standard way of representing various enterprise objects. By defining a standard way to describe these objects using XSD they are able to manage and guarantee the various data formats. I was working with a customer the other day and they were interested in how they could create an extensible schema. They wanted to create a standard representation of their employees, but provide the way for each of their subsidiaries to extend (not change) the underlying structure. I am going to present three examples that show this. For ease of clarity I will use InfoPath. Of course, these same concepts can be extended to anything XSD compliant.

By default, anything like an InfoPath form created using an XSD is considered locked. This means that form designers or developers are unable to add new elements or attributes to the data structure. This by design makes sense when you consider the fact that the purpose of XSD is to guarantee a specific format to the data structure. Of course, the flexibility of the XSD design allows for extensible elements to be added as we will see in later example.

Example 1: The Locked Schema

Starting with the XSD defined below that describes an employee

<?xml version="1.0"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3.org/2001/XMLSchema">

<element name="prefix" type="string"/>

<element name="firstname" type="string"/>

<element name="lastname" type="string"/>

<element name="suffix" type="string"/>

<element name="email" type="string"/>

<element name="employeeid" type="string"/>

<element name="costcenter" type="string"/>

<element name="employeeinfo">

<complexType>

<sequence>

<element ref="prefix" minOccurs="0"/>

<element ref="firstname"/>

<element ref="lastname"/>

<element ref="suffix" minOccurs="0"/>

<element ref="email"/>

<element ref="employeeid"/>

<element ref="costcenter"/>

</sequence>

</complexType>

</element>

</schema>

Using this XSD to create an InfoPath form creates a locked form as shown below. The data source window within InfoPath actually adds a locked icon to the entire data source for visual display.

Even if a form designer attempts to right click and add a new element or attribute the “add” menu is grayed out as shown below.

Example 2: Extending Elements

If we change the XSD schema to include the “any” element attribute as shown below. This allows additional elements to be added to the XSD data structure.

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="prefix" type="xsd:string"/>

<xsd:element name="firstname" type="xsd:string"/>

<xsd:element name="lastname" type="xsd:string"/>

<xsd:element name="suffix" type="xsd:string"/>

<xsd:element name="email" type="xsd:string"/>

<xsd:element name="employeeid" type="xsd:string"/>

<xsd:element name="costcenter" type="xsd:string"/>

<xsd:element name="employeeinfo">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="prefix" minOccurs="0"/>

<xsd:element ref="firstname"/>

<xsd:element ref="lastname"/>

<xsd:element ref="suffix" minOccurs="0"/>

<xsd:element ref="email"/>

<xsd:element ref="employeeid"/>

<xsd:element ref="costcenter"/>

<xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Using the above XSD to create an InfoPath form creates a slightly different data source. The appearance of the lock icons appears at the field level.

I am now allowed to add additional elements to the data source.

Example 3: Extending Attributes

If we change the XSD slightly and add in the “any” attribute.

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="prefix" type="xsd:string"/>

<xsd:element name="firstname" type="xsd:string"/>

<xsd:element name="lastname" type="xsd:string"/>

<xsd:element name="suffix" type="xsd:string"/>

<xsd:element name="email" type="xsd:string"/>

<xsd:element name="employeeid" type="xsd:string"/>

<xsd:element name="costcenter" type="xsd:string"/>

<xsd:element name="employeeinfo">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="prefix" minOccurs="0"/>

<xsd:element ref="firstname"/>

<xsd:element ref="lastname"/>

<xsd:element ref="suffix" minOccurs="0"/>

<xsd:element ref="email"/>

<xsd:element ref="employeeid"/>

<xsd:element ref="costcenter"/>

</xsd:sequence>

<xsd:anyAttribute/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Once again creating an InfoPath form the locks appear the same.

However, right clicking and selecting “add” to the data source allows only field level attributes to be added as shown below.

This was meant to show only some of the features available within XSD. The XSD standard defines a very robust and well defined set of tags.

Email received:

I have installed the SP 1 preview of InfoPath and recently completed the design of a form. The form doesn’t use any of the new features. Actually, I had designed it using the original InfoPath and accidentally upgraded it. Is there a way to remove the SP 1 features?

Answer:

Absolutely, if you have a form and need to turn off the upgrade follow these steps.

1. Open the form in design mode.

2. Once in design mode you then select Tools -> Form Options

3. Select the Advanced tab. At the bottom you can then click the export button and save the form. This will save the form as an InfoPath 1.0 form.

Now, once you have the form in compatibility mode, or if you need to design a form using InfoPath 1.0 make sure that you turn off the SP 1 features. Follow these steps to turn off the features in the Service Pack.

1. Open InfoPath and select the Tools -> Options menu

2. Select the Advanced tab and click the first box “Disable Service Pack Features”.

Once you close and reopen InfoPath, any forms that you open are no longer using or taking advantage of the InfoPath SP 1 features.