What Is an XML Schema?

Schemas describe an object and any of the inter-relationships that exist within a data structure. There are many different types of schema definitions. Relational databases like SQL Server use schemas to contain the table names and column keys, and provide a repository for trigger and stored procedures. Within class definitions, developers define schemas to provide the object-oriented (OO) interface to properties, methods , and events. Within an XML data structure, schemas describe both the object definition and the relationship of data elements and attributes. Regardless of the context that schemas are used in, they provide the data representation and serve as an abstracted data layer. Schemas define the object design that established the implementation framework of a particular object.

XML is really a metalanguage used to create and describe other languages. XML Schema Definition (XSD) is an example of an XML-based modeling language defined by the W3C for creating XML schemas. Represented in XML, XSD defines and enforces the legal building blocks for formatting and validating an XML file. InfoPath stores completed forms as XML documents based on the XSD defined during form design.

Creating a Data Source

Whenever a form template is created, an XSD is also created and stored within the InfoPath solution file. InfoPath maintains and accesses these schemas through data sources. The data source is responsible for storing all the data entered into a form. It is structured as fields, attributes, and groups. Inside the data source, a group is a set of XML elements that serve as a container for fields and attributes. When an InfoPath solution is opened, the form binds controls to the data source based on the defined data type and uses this to save the field-level data.

 CD-ROM     Listing 3.1 shows the XML file that describes an employee (it is also available on the companion CD-ROM, in \Code\Chapter 3\EmployeeInformation\Employeexml.xml). InfoPath automatically creates a data source based on this and defines it within the form template file.

Listing 3.1: An XML file that describes an employee.

 <?xml version="1.0" encoding="utf-8"?> <employeeinfo> <prefix>Mr</prefix> <firstname>Thomas</firstname> <lastname>Robbins</lastname> <suffix></suffix> <email>[e-mail]</email> <employeeid>191912</employeeid> <costcenter>1200</costcenter> <employeeurl>http://www.company.com/trobbins</employeeurl> </employeeinfo> 

 

Within InfoPath we can select the new data source option, as shown in Figure 3.1, from the design menu.

Figure 3.1: The Data Source Setup Wizard screen.

Using the structure of the employee XML file, InfoPath defines and implements an XSD schema based on the structure of this file. After the creation of the XSD, InfoPath form designers are given an option to assign the XML values as the default global values, as shown in Figure 3.2. These values become built into the form template and any new forms are automatically assigned these.

Figure 3.2: Defining a set of global defaults.

 CD-ROM     Extract the individual InfoPath files into a file directory from the solution using the Extract Form Files function available on the file menu. The extracted file  schema.xsd , shown in Listing 3.2 and provided on the companion CD-ROM, contains a defined schema. (\Code\Chapter 3\EmployeeInformation\Extracted is a file directory that contains the extracted files.)

Listing 3.2: The schema.xsd file defined within the InfoPath solution.

 <?xml version="1.0" encoding="utf-8" standalone="no"?> <xsd:schema xmlns:my="http://schemas.microsoft.com/office/infopath/ 2003/myXSD/2003-06-28T23:01:09" xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <xsd:element name="employeeinfo">     <xsd:complexType>       <xsd:all>         <xsd:element ref="prefix" minOccurs="0"/>         <xsd:element ref="firstname" minOccurs="0"/>         <xsd:element ref="lastname" minOccurs="0"/>         <xsd:element ref="suffix" minOccurs="0"/>         <xsd:element ref="email" minOccurs="0"/>         <xsd:element ref="employeeid" minOccurs="0"/>         <xsd:element ref="costcenter" minOccurs="0"/>         <xsd:element ref="employeeurl" minOccurs="0"/>       </xsd:all>       <xsd:anyAttribute processContents="lax"  namespace="http://www.w3.org/XML/1998/namespace"/>     </xsd:complexType>   </xsd:element>   <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="employeeurl" type="xsd:string"/> </xsd:schema> 

 

XSD Schema Definitions

All XSD schemas contain a single top-level element. Underneath this element is the schema element that contains either simple or complex type elements. Simple elements contain text-only information. Complex elements are a grouping element that acts as a container for other elements and attributes. There are four types of complex elements: empty elements, elements that contain other elements, elements that contain only text, and elements that contain both other elements and text.

The XML employee file that we created above was generated using Notepad and then submitted to InfoPath. InfoPath then took the XML output file and created an XSD representation that matched the defined format. Let s create the same schema representation manually using XSD. Instead of having InfoPath generate the XSD based on a XML data file, we will provide the exact schema representation that we want InfoPath to use.

 CD-ROM     The result, shown in Listing 3.3, is available on the companion CD-ROM (\Code\Chapter 3\ExtendableSchema\defaultemployee.xml). One thing you will notice, as we will see later in this chapter, is that this schema is not extensible and we will need to change the attributes to allow this.

Listing 3.3: XSD representing an employee.

 <?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="employeeurl" 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="employeeurl"/>     <xsd:element ref="costcenter"/>   </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 

 

The simple types contain the individual elements or fields that describe the employee object. These are then grouped into a complex type ( employeeinfo ) that provides the entire object representation.

Extending Schemas with Validation

XSD enables schemas to include more than just simple object definitions that define structure and context. When you use XSD, a schema can provide validation on both elements and attributes. Table 3.1 shows a number of validations that can be defined within XSD and that can be applied to XML documents.

Table 3.1: Types of validation supported by XSD.

Validation Type	Description
Data Type	Schemas can control the expected data type of an element or attribute.
Constraints	Schemas can limit the allowed values of an element to include length, pattern, or minimum or maximum value.
Cardinality	Schemas can control the number of specific element occurrences. For example, a specific element may be allowed only once, or one or more times within an attribute or element.
Choice	Schemas can limit the available choices within a selection list.
Sequence	Schemas can define the order that elements are used in. For example, a business name may require multiple address types.
Defaults	Schemas can define a default value that is used when no other value is specified. This is the XSD feature that InfoPath uses when defining global default values.

 CD-ROM     To create validation rules within a schema, you use a simple type element that defines the specific validation type. The following XSD snippet, available on the companion CD-ROM in \Code\Chapter 3\Timesheet\schema\restriction.xsd, shows how to force a validation rule on the employeeurl that enables inheritance based on a pattern restriction.

 <xsd:simpletype name="weburl">   <xsd:restriction base="xsd:string">   <xsd:pattern value="http://.*"/>   </xsd:restriction> </xsd:simpletype> 

Once the simple type definition is completed, this then becomes a base data type webURL defined within the document that enforces an HTTP pattern. In order to apply the constraint on the employeeurl field, change the data type to the newly defined simple type, as shown here:

 <xsd:element name="employeeurl" type="weburl"/> 

Many times, XML documents contain key required fields that needed to define an object reference. Within the employee file this includes first name, last name, and employee id. Enforcing cardinality within a data structure is done through the instance element. This element can define either a minimum or maximum amount of times that the specific element must exist, as you can see here:

 <xsd:simpletype name="requiredstring">   <xsd:restriction base="xsd:string">   <xsd:minLength value="1"/>   </xsd:restriction> </xsd:simpletype> 

One of the built-in benefits of XSD is inheritance. This enables any of the base elements that are defined within the employee schema to inherit from a new derived base type of requiredString , as shown here:

 <xsd:element name="firstname" type="requiredstring"/> <xsd:element name="lastname" type="requiredString"/> <xsd:element name="employeeid" type="requiredstring"/> 

 CD-ROM     Using the newly defined XSD, InfoPath can define a data source based on the constrained schema, as shown in Figure 3.3. Contained on the CD-ROM (in \Code\Chapter 3\Timesheet\schema\restriction.xsd) is the full text of the base XSD schemas that are defined in this example.

Figure 3.3: The data source of an InfoPath form using the constrained schema.

What Are Namespaces?

Namespaces are an optional set of declarations at the top of an XSD file. They provide a unique set of identifiers that associate a set of XML elements and attributes together. The original namespace in XML specification was released by the W3C as a URI-based way to differentiate various XML vocabularies. This was then extended under the XML schema specification to include schema components and not just single elements and attributes. The unique identifier was redefined as a URI that doesn t point to a physical location but to a security boundary that the schema author owns. The namespace is defined through two declarations: the XML schema namespace and the target namespace . The xmlns attribute uniquely defines a schema namespace and is then divided into three sections:

• xmlns Keyword: This is defined first and separate from the target namespace prefix by a colon .

• Prefix: This defines the abbreviated unique name of a namespace and is used when you are declaring all elements and attributes. Both xmlns and xml are reserved keywords that can t be used as valid prefixes.

• Definition: This is the unique URI that identifies the namespace and contains the security boundary owned by the schema author.

Anytime an xmlns attribute is defined within an XML document, any element or attribute that belongs to that namespace must contain the prefix. A variety of standard namespace definitions are available for use within schema structures, as shown here:

 XML Schema Namespace - xmlns:xsd=http://www.w3.org/2001/XMLschema. XSLT Transform Namespace: -  xmlns:xsl=http://www.w3.org/1999/XSL/Transform . InfoPath namespace: - xmlns:my=http://schemas.microsoft.com/office/infopath/2003 

The target namespace attribute identifies the schema components described within the current document. This attribute acts as a shortcut method for describing the elements in the current schema. There are three variations in how the namespace and target namespace attributes can be combined within a valid XSD document. The full text of each approach, including the full XSD that is defined for each approach, is on the CD-ROM.

 CD-ROM     Approach 1 is where there is no default namespace. (You can find the full text of this approach on the companion CD-ROM in \Code\Chapter 3\Namespace\  Approach1.xsd .) If there is no default namespace, then the XSD must qualify both the XML schema and the target namespace, as shown in Figure 3.4.

Figure 3.4: Fully qualifying the XML schema and target namespace.

With no default namespace, all schema components are explicitly qualified, including components in the target namespace. Even though it may look a little cluttered, all elements have a consistent defined set of references.

Approach 2 is where you define a default XML schema. (You can find the full text of this approach on the companion CD-ROM in \Code\Chapter 3\Namespace\Approach2.xsd.) Defining a default schema allows you to remove default reference elements within an XSD, as shown in Figure 3.5.

Figure 3.5: Defining a default schema.

The default assigned namespace is valid for all XML-defined XML schema definitions. This approach becomes more limited than the other approaches as the complexity of a schema document increases ; however, this approach is the easiest of the three to both read and understand within a schema document.

Approach 3 is where you qualify the XML schema. (You can find the full text of this approach on the companion CD-ROM in \Code\Chapter 3\Namespace\  Approach3.xsd .) If both the target namespace and default namespace are defined, you don t need to qualify the employee reference, as shown in Figure 3.6.

Figure 3.6: An XML schema with no qualification.

This scenario is actually the mirror image of Approach 1, where the target namespace is also defined as the default. When you use Approach 3, all portions of the XSD must be fully qualified within a document. This is by far the easiest approach for maintaining readability, but it becomes a bit cluttered as additional namespaces are added, as we will see later in this chapter as we create more complex schema definitions.

Unlocking the InfoPath Schema

Regardless of the design pattern, XML schemas imported into InfoPath are by default read only, as you may remember earlier from our discussion of the employee schema. This is a design feature of InfoPath that preserves the integrity and intent of the original schema definition. Within InfoPath, this prevents the form designer from initializing the automatic data source engine and adding or removing required elements. Within the designer, the schema appears locked, as shown in Figure 3.7. Schema designers can add the XSD < any > attribute to allow authors to extend XML documents with elements not specified by the schema.

Figure 3.7: A schema showing as locked.

 CD-ROM     When you apply the XSD < any > attribute to the original employee schema, this enables you to include other namespaces. For example, within the InfoPath designer this would allow you to include the default InfoPath namespace and allow additions to the schema. This is shown in Listing 3.4, which is also available on the companion CD-ROM (\Code\Chapter 3\ExtendableSchema\Anyattribute.xsd).

Listing 3.4: A sample XML schema that appears as extensible within InfoPath.

 <?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> 

 

 CD-ROM     Using another variation, shown in Listing 3.5 and available on the companion CD-ROM (\Code\Chapter 3\Namespace\AnyElement.xsd), allows you to include other attributes with non-schema namespaces specified in the original definition.

Listing 3.5: An extensible schema that allows you to add non-schema namespaces.

 <?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> 

 

The < any > attribute is an important part of schema definitions within the enterprise. When you re designing XSDs for use within InfoPath, this attribute enables extensibility within the designer. For example, solutions that leverage external schemas often require extensibility within a solution.

The Employee Timesheet Application

Many organizations already have a variety of schemas defined and being used. The nature of a schema represents a consistent set of values and definitions about an object. The benefit is that this consistent representation is reusable in a variety of solutions and enables a consistent enterprise vocabulary. For example, timesheets are often a combination of various objects and relationships.

Note  

The entire Employee Timesheet application is included on the companion CD-ROM (\Code\Chapter 3\Timesheet\  timesheet.xsd ).

Schema Inheritance

Through their namespaces, individual XSD schemas are provided a level of independence and isolation for the objects they describe. A main objective of the XML schema definition was to promote reusability and enable inheritance. You can do this by creating a composite object, the combination of individual namespaces to form a new inherited object relationship. The timesheet application represents the combining of the company and employee into a new timesheet object with the structure shown in Figure 3.8.

Figure 3.8: The structure of the timesheet.xsd.

Enabling schema inheritance is a two-step process:

1. Add each individual namespace into the  timesheet.xsd , as shown here:

    <xsd:schematargetNamespace="http://schemas.mycompany.com/ns/timesheet/  info" xmlns:employee="http://schemas.mycompany.com/ns/employees/info"  xmlns:restriction="http://schemas.mycompany.com/ns/restriction/info"  xmlns:company="http://schemas.mycompany.com/ns/company/info"  xmlns:timesheet="http://schemas.mycompany.com/ns/timesheet/info"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 

2. Issue the import statement to enable the XML parser with a physical path to the inherited schemas, as shown here:

    <xsd:import namespace="http://schemas.mycompany.com/ns/company/info"  schemaLocation="company.xsd"/> <xsd:import namespace="http://schemas.mycompany.com/ns/employees/info"  schemaLocation="employee.xsd"/> <xsd:import namespace="http://schemas.mycompany.com/ns/restriction/info"  schemaLocation="restriction.xsd"/> 

Defining an Enumeration Dropdown

Value spaces are declared within an XSD as a set of defined enumerations within a data type. Each value is represented by a set of defined literal values using the enumeration element. This forces a data type restriction that allows a value to contain one or more list items. Within the timesheet schema, this is used to enforce cardinality for the work type element, as shown here:

 <xsd:simpleType name="worktypes">   <xsd:restriction base="xsd:string">   <xsd:enumeration value="Regular"/>   <xsd:enumeration value="Vacation"/>   <xsd:enumeration value="Sick"/>   </xsd:restriction> </xsd:simpleType> 

When imported into InfoPath, the data source converts and renders this as a drop-down list box that contains the defined enumerations, as shown in Figure 3.9.

Figure 3.9: Field properties showing an enumeration.

Repeating Sections

Within the InfoPath designer, repeating sections are a data source grouping that can occur more than once. Controls within the data source are bound to either sections or tables that allow for multiple field entry. Within the timesheet schema, this

allows users to enter the daily time. As part of the XSD schema, this is defined using the < maxoccurs > attribute and setting the value to unbounded , as shown here:

 <xsd:element ref="timesheet:weekof" minOccurs="0" maxOccurs="unbounded"/> 

When the completed timesheet schema is imported into InfoPath, the data source translates and renders this as a repeating section on the Data Source tab, as shown in Figure 3.10.

Figure 3.10: An imported schema showing a repeating section.

Setting Default Values

It is the responsibility of both the schema and forms designer to make form entry as simple and quick as possible for end users. One of the ways to accomplish this type of design requirement is to set default values. These values attach either the initial or expected values to element definitions within the schema structure. Ideally, these are fields that always contain the same value. As an example, within the company schema, name is a required field that by default contains the same value. Using XSD, you can define a default value using the default property value of the element definition, as shown in the following line:

 <xsd:element name="name" type="restriction:requiredString"  default="Extra Large Inc."/> 

The InfoPath data source attaches the default value to the element definition and marks the field required, as shown in Figure 3.11.

Figure 3.11: The company name default value.

Form Design

The  timesheet.xsd file represents a completed schema that defines the timesheet object. This object uses both inherited and extended XSD elements and extensions. Once this is imported into InfoPath, the next step to developing the timesheet application is form design. Form development using InfoPath is similar to traditional Web-based development that use tables as container structures for data entry items.

Creating the Form Header

Forms are designed from the top down. The top-level table is considered the form header that contains the form name and any instructions for completing the form. Within the timesheet application, this is a two-column layout table. One column contains a form graphic and the other contains the form instructions, as shown in Figure 3.12.

Figure 3.12: View of a layout table.

The form graphic is defined as an external resource object. These types of resources are maintained as part of the solution (.xsn) file and defined within the form manifest document. InfoPath applications deployed as part of an intranet solution are required only to provide a file path or URL to the location of the resource. Any other deployment type requires the resource to be stored within the solution file, with the manifest maintaining a reference back to itself. In this scenario, the size of the resource directly impacts the overall size of the solution file. When a form is loaded, the manifest file provides a handle to the data source that binds this to a picture control for display within the form.

Defining the Input Area

Once the form header is complete, the form designer can then move into the design of the data entry area of a form. The Timesheet application captures input using a custom table. This type of layout table allows you to visually define the number of columns and rows contained in a table, as shown in Figure 3.13.

Figure 3.13: Defining a custom table.

All InfoPath tables are fixed width during rendering instead of being HTML percentage-width tables. This is mostly to circumvent the performance hit that typically occurs with this type of rendering. During the InfoPath rendering process, the engine always defaults back to the fixed-width table definitions defined during the design process. As fields are dropped onto the design surface, they expand to the width of the current table column.

InfoPath does allow the fields within a table to be adjusted. The control property page within the form allows you to define both the width and height of specific controls through the data source, as shown in Figure 3.14. Using the property pages, you can reduce the sizes of the employee name fields and place them on the same data entry line. The auto-size function in the height column adjusts column width based on the size of the table. Only the list box and drop-down list box adjust the width based on the amount of fields shown within a table cell .

Figure 3.14: Setting the width of a field.

Color schemes are another way for designers to customize forms. In design mode, a color scheme can be applied to a form, as shown in Figure 3.15. This scheme is applied to the XSL style sheet that is used to render the form. Depending on the way a form is designed, these schemes can include body and heading styles, table cells , and row borders.

Figure 3.15: Changing the color scheme.