Using W3C XML Schema

W3C XML Schema forms the backbone of validation in InfoPath 2003. Whichever type of data source you choose when designing a form template, InfoPath will use a pre-existing W3C XML Schema document, create a W3C XML Schema document by interpreting the permitted structure of a database or XML Web service, or attempt to create a W3C XML Schema document from an example XML document.

One of the advantages of W3C XML Schema as a validation technology is that it can be used unchanged on both the client side and the server side. Therefore, the amount of work required to ensure that the client-side and server-side validation follow identical logic is significantly reduced when compared to HTML forms, where the language used on the client side might be different from the language used on the server side. When using InfoPath, you can use W3C XML Schema to ensure that only valid data can be submitted to the server side. Or, if the server process already has a W3C XML Schema document, you need to ensure that the same W3C XML Schema document(s) are used on the client side.

W3C XML Schema Crash Course

W3C XML Schema is a huge and complex language. This section briefly summarizes some key points. If you are unfamiliar with W3C XML Schema, I suggest you consult a general XML book such as Sams Teach Yourself XML in 21 Days by Steve Holzner for basic information. If you need to understand W3C XML Schema in more depth, you can visit http://www.w3c.org/XML/Schema#dev. Of the W3C documents, the W3C XML Schema Primer at http://www.w3c.org/TR/xmlschema-0/ is the most readable. Alternatively, you might want to consult a dedicated W3C XML Schema book, such as XML Schema Essentials (Wiley), which I co- authored .

A W3C XML Schema document defines the allowed structure and data types of a class of XML documents. The document has a schema element in the namespace http://www.w3.org/2001/XMLSchema as its document element, with commonly used namespace prefixes being xsd or xs . All other elements that form part of the schema are nested inside the xsd:schema element.

In simple W3C XML Schema documents, you can expect to find an xsd:element element nested as a child of the xsd:schema element, which indicates the document element.

For example, a skeleton schema for a class of XML documents that has a books element as its document element would look like this:

 <xsd:schema> <xsd:element name="books" type="booksType" /> <!-- Remainder of schema goes here --> </xsd:schema> 

The name attribute of the xsd:element element indicates that a books element must exist in XML documents in the class of documents to which the schema applies. The value of the type attribute specifies that the books element has content of the booksType data type ”a user -defined data type.

The xsd:complexType element can be used to specify a W3C XML Schema complex type. A complex type definition specifies that the element whose type is being defined has child elements or attributes, or both. For example, to specify that the books element can have as its child element only book elements, we can use the xsd:sequence element nested inside the xsd:complexType element, which defines the booksType data type:

 <xsd:schema> <xsd:element name="books" type="booksType" /> <xsd:complexType name="booksType">  <xsd:sequence>  <xsd:element name="book" minOccurs="0" maxOccurs="unbounded" type="bookType"/>  </xsd:sequence> </xsd:complexType> <!-- Remainder of schema goes here --> </xsd:schema> 

Notice that the booksType data type is used in relation to the books (plural) element, and the bookType data type is used in relation to the book (singular) element.

The xsd:sequence element indicates that its content is a sequence of elements. In this case, we have the simplest scenario: a sequence of book elements. In other words, the only allowed child elements of the books element are book elements. The minOccurs and maxOccurs attributes of the xsd:element element indicate that the book element is optional (for example, to allow for the scenario when a document is first created and a book description has not yet been added), or can occur an unbounded number of times.

So, our class of instance documents would look like this:

 <books>  <book>  <!-- Content yet to be defined -->  </book>  <book>  <!-- Content yet to be defined -->  </book>  <!-- and so on ... --> </books> 

Both the schema (the bookType data type hasn't yet been defined) and the instance document indicate that we need to define the allowed content of a book element. In the updated schema document, we add a bookType data type and authorsType and editorsType data types:

 <xsd:schema> <xsd:element name="books" type="booksType" /> <xsd:complexType name="booksType">  <xsd:sequence>  <xsd:element name="book" minOccurs="0" maxOccurs="unbounded" type="bookType"/>  </xsd:sequence> </xsd:complexType> <xsd:complexType name="bookType">  <xsd:sequence>  <xsd:element name="title" type="xsd:string" />  <xsd:choice>  <xsd:element name="authors" type="authorsType" />  <xsd:element name="editors" type="editorsType" />  </xsd:choice>  <xsd:element name="Publisher" type="xsd:string" />  <xsd:sequence> </xsd:complexType> <xsd:complexType name="authorsType">  <xsd:sequence>  <xsd:element name="author" minOccurs="1" maxOccurs="unbounded" type="xsd:string" />  </xsd:sequence> </xsd:complexType> <xsd:complexType name="editorsType">  <xsd:sequence>  <xsd:element name="editor" minOccurs="1" maxOccurs="unbounded" type="xsd:string" />  </xsd:sequence> </xsd:complexType> </xsd:schema> 

Notice the content of the bookType data type definition. A book element consists of a sequence of elements, indicated by an xsd:sequence element as before. First, there is a title element. Next in the sequence is a choice of an editors element or an authors element, indicated by the xsd:choice element. Finally, there is a Publisher element. The title element and the Publisher element have simple type content; in this case, the data type is xsd:string , one of the built-in W3C XML Schema data types. However, the editors element is of type editorsType and the authors element is of type authorsType , and these are defined in the remainder of the schema document as a sequence of editor elements and author elements, respectively. Both editor elements and author elements have simple type content of type xsd:string .

Putting all that together, the class of XML documents would look something like this:

 <books> <book>  <title></title>  <authors>  <author></author>  <author></author>  </authors>  <Publisher></Publisher> </book> <book>  <title></title>  <editors>  <editor></editor>  <editor></editor>  </editors>  <Publisher></Publisher> </book> <!-- More <book> elements can go here. --> </books> 

There is much, much more to W3C XML Schema than in this brief introduction, but this discussion gives you an impression of what a W3C XML Schema document consists of and how it relates to defining the structure of a class of XML documents. Because InfoPath submits data as XML, W3C XML Schema can, in some circumstances, be all you need to fully define the data that is queried by or submitted by an InfoPath form.

A W3C XML Schema from an XML Instance Document

When InfoPath automatically creates a schema document, there are inevitable uncertainties. For example, if the schema is created from a sample XML document such as Listing 10.1, how can we be sure how many book or author elements are allowed?

Listing 10.1. An XML Instance Document ( Books.xml )

 <books>  <book>  <title>Teach Yourself XML in 10 Minutes</title>  <author>Andrew Watt</author>  <publisher>Sams Publishing</publisher>  </book>  <book>  <title>SVG Unleashed</title>  <author>Andrew Watt</author>  <author>Chris Lilley</author>  <author>Daniel J. Ayers</author>  <author>Randy George</author>  <author>Christian Wenz</author>  <author>Tobias Hauser</author>  <author>Kevin Lindsey</author>  <author>Niklas Gustavsson</author>  <publisher>Sams Publishing</publisher>  </book> </books> 

The two books for which sample data exists show that a book element can occur twice inside a books element. Is it essential that a book element occur exactly twice, or can it occur once, or can it be optional (that is, occur zero times)? Can a book element occur three or more times inside a books element? We don't know from a single instance document ”although we can make some guesses ”but there is always some residual uncertainty.

Similarly, for one book shown above, there is a single author element, and for the other book there are eight author elements. Can a book have zero authors (for example, books that have an editor)? Or nine authors? Or an unlimited number? We can't be absolutely sure.

Questions about data types might also arise. For example, if we want to add a year element to the content of each book element, should its data type be a string or an integer?

The importance of uncertainties such as these depends on what you plan to do with your data. Using an XML instance document avoids the need to be fluent in using W3C XML Schema but leaves these potential uncertainties about the schema InfoPath creates. If you need more precision, you need to use a W3C XML Schema document, rather than an XML instance document.

W3C Schema from Database Schema

InfoPath can create a W3C XML Schema document from a database schema. For example, Listing 10.2 shows a W3C XML Schema document automatically created for the SimpleDBAccess.xsn form template example.

Listing 10.2. A W3C XML Schema Document ( schema.xsd )

 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <xsd:schema  targetNamespace="http://schemas.microsoft.com/office/infopath/2003/dataFormSolution"  elementFormDefault="qualified"  attributeFormDefault="unqualified"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:dfs="http://schemas.microsoft.com/office/infopath/2003/dataFormSolution"  xmlns:d="http://schemas.microsoft.com/office/infopath/2003/ado/dataFields"  xmlns:q="http://schemas.microsoft.com/office/infopath/2003/ado/queryFields">  <xsd:import  namespace="http://schemas.microsoft.com/office/infopath/2003/ado/dataFields"  schemaLocation="schema1.xsd"/>  <xsd:import  namespace="http://schemas.microsoft.com/office/infopath/2003/ado/queryFields"  schemaLocation="schema2.xsd"/>  <xsd:element name="myFields">  <xsd:complexType>  <xsd:sequence>  <xsd:element name="queryFields">  <xsd:complexType>  <xsd:sequence>  <xsd:element ref="q:Person" minOccurs="0" maxOccurs="1"/>  </xsd:sequence>  </xsd:complexType>  </xsd:element>  <xsd:element name="dataFields">  <xsd:complexType>  <xsd:sequence>  <xsd:element ref="d:Person" minOccurs="0" maxOccurs="unbounded"/>  </xsd:sequence>  </xsd:complexType>  </xsd:element>  <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>  </xsd:sequence>  <xsd:anyAttribute namespace="##other" processContents="lax"/>  </xsd:complexType>  </xsd:element> </xsd:schema> 

When creating a schema from a relational database schema, InfoPath may create several W3C XML Schema documents. Notice in Listing 10.2 that the schemaLocation attributes of the xsd:import elements reference two other W3C XML Schema documents, schema1.xsd and schema2.xsd . Those, in turn , are treated as if they are part of the main schema document. Notice that the namespace URI for the imported documents indicates that schema1.xsd contains the schema of the data fields, and schema2.xsd contains the schema of the query fields of the InfoPath data source. Listing 10.3 shows schema1.xsd in full.

Listing 10.3. An Imported W3C XML Schema Document ( schema1.xsd )

 <?xml version="1.0" encoding="UTF-8" standalone="no"?> <xsd:schema targetNamespace="http://schemas.microsoft.com/office/infopath/2003/ado/dataFields"  elementFormDefault="unqualified"  attributeFormDefault="unqualified"  xmlns:xsd="http://www.w3.org/2001/XMLSchema"  xmlns:d="http://schemas.microsoft.com/office/infopath/2003/ado/dataFields">  <xsd:element name="Person">  <xsd:complexType>  <xsd:attribute name="ID" type="d:optional_int"/>  <xsd:attribute name="FirstName" use="optional">  <xsd:simpleType>  <xsd:restriction base="xsd:string">  <xsd:maxLength value="50"/>  </xsd:restriction>  </xsd:simpleType>  </xsd:attribute>  <xsd:attribute name="LastName" use="optional">  <xsd:simpleType>  <xsd:restriction base="xsd:string">  <xsd:maxLength value="50"/>  </xsd:restriction>  </xsd:simpleType>  </xsd:attribute>  <xsd:anyAttribute namespace="http://schemas.microsoft.com/office/infopath/2003/adomapping" processContents="skip"/>  </xsd:complexType>  </xsd:element>  <xsd:simpleType name="optional">  <xsd:restriction base="xsd:string">  <xsd:maxLength value="0"/>  </xsd:restriction>  </xsd:simpleType>  <xsd:simpleType name="optional_int">  <xsd:union memberTypes="xsd:int d:optional"/>  </xsd:simpleType> </xsd:schema> 

Listing 10.3 introduces a few W3C XML Schema constructs that you haven't seen before. For example, the content of the xsd:element element, which declares the Person element, is an anonymous complex type. Instead of the xsd:element element having a type attribute, along with a corresponding xsd:complexType element somewhere else in the schema document, the xsd:complexType element (without a name attribute) is nested inside the xsd:element element. The absence of a name attribute indicates an anonymous type.

Notice too that the declaration for the FirstName attribute includes an xsd:restriction element. The value of the base attribute of the xsd:restriction element indicates that it is a string value that's being restricted. The xsd:string data type is built in to W3C XML Schema processors. The value attribute of the xsd:maxLength element specifies that the maximum length of the string is 50 characters . This, of course, corresponds to the table definition for the corresponding field of the Access database (see Figure 10.6).

Figure 10.6. The length definition of the FirstName field in the Access table.