26.1. System Architecture

Most distributed architectures discuss three tiers in the development of Web-based applications, but the Web Server tier should really be thought of as a separate layer. In fact, as we move closer and closer to Web services this layer might be replaced altogether. Therefore, the layers modeled for the CRSS are:

• Client tier

• Web Server tier

• Application tier

• Database tier

Let’s look at each tier and the technologies used today. The Client tier typically consists of HTML and JavaScript for computers and Wireless Markup Language (WML) for PDAs. It is possible to embed many other controls (Shockwave, applets, ActiveX), but we will exclude these plug-in technologies from our application.

The simplest way to model the application is to start with high-level architectural diagrams and then model the tiers one at a time.

The architecture shown in Figure 26.1 has been used in many applications for quite a few years now. In fact, the success of this architecture has accelerated the acceptance and emergence of XML standards.

You might wonder why XML Schema and the other XML concepts should be introduced to the mix illustrated in Figure 26.1. We certainly have enough acronyms without introducing all the X-based ones. You should not start to use all these X technologies without a good justification. Properly justifying the use of XML-based technologies will seem simple if you have already been dealing with some of the following issues:

• HTML browsers do not comply with rigid standards. This might not be a stunning revelation to any Web developer who has been up all night sorting out a Netscape versus Internet Explorer issue. Use XML with XSLT to produce well-formed HTML—or better yet, XHTML.

• The Web Server tier in Figure 26.1 has many competing technologies. Learning all of them is difficult. They are all trying to do the same thing: accept user inputs as HTTP messages and format the output results as HTML or WML. Many applications have misused the Web server layer and placed far too much validation and business logic in it. Maintaining these projects is extremely difficult. The technologies are simplified dramatically if you switch to XML-based technologies and use XML schemas to perform the validation.

• The Component tier is certainly the most interesting. You have the never-ending debate about Java versus anything else. What is frequently lost in this debate is the real purpose of this tier, which is to provide business logic. Business logic is based on data, and XML is tailor-made for manipulating data. By using XML, you can simplify your components by passing XML nodes back and forth. Each node can use an XML schema for its test case. This eliminates the need to write software to test software—a classic Catch-22. If you ask Web developers how they test an application, they’re likely to say they open Netscape and Internet Explorer and verify that the application works. Could you imagine testing a new aircraft wing by installing it on a plane and taking it up for a flight? If it works once, will it work every time? Will it work with all revisions? Obviously, much better test methodology is required.

• The Database tier is a moving target right now. Both Microsoft and Oracle are rapidly adding XML capabilities to their databases. These capabilities enable you to use XML messages to request database actions, eliminating all the formatting required in an Active Server Page/Active Data Object (ASP/ADO) solution or corresponding Java Server Page/Java Database Connectivity (JSP/JDBC) scenario.

Our Campus Resource and Schedule System (CRSS) case study uses XML as its foundation, which is illustrated in Figure 26.2. When comparing Figure 26.2 to Figure 26.1, the most striking difference is the reliance on XML across all the tiers.

As you can see from Figure 26.2, XML technologies do not replace HTML, JavaScript, .NET, Java, or SQL. XML simply is used by these technologies to increase their reliability and robustness.

In the model in Figure 26.2, XML schemas are used in two ways:

• Defining interfaces between different processes or tiers

• Validating data

Figure 26.2 shows that the Web tier converts an incoming HTTP request into an XML message. This message is validated against an XML schema. Once you have valid user input, the message is sent to the Component tier where business logic is applied. Database access is also accomplished with XML messages.

The challenge at the database interface is different than at the user interface. You can ensure that your components are producing valid XML in the design of the components, but you need to map the data from an XML source to a relational database format and vice versa. XML schemas can provide the hierarchical to relational mapping, as you will see a bit later.

Interfaces between all three tiers are simplified when using XML. Testing at all interfaces is accomplished using XML schemas. This ability to test the interfaces declaratively allows software projects to be worked on by teams more easily.

You will begin the CRSS application by modeling the Client tier to the Web Server tier. You will model each requirement by using UML sequence diagrams. Then you will convert each of these sequence diagrams into XML messages. These messages define the workflow of the application.

Let’s start by modeling the following requirement: View existing reservations on a per resource basis.

Obviously, user input will be required. You need to support multiple devices, but let’s start by assuming a browser interface. As you will see later, implementing the support for any other Web-enabled device is easy. The sequence diagram in Figure 26.3 models the first requirement.

You can see from the sequence diagram in Figure 26.3 that each tier is modeled by an interface. There is a Web interface that can be implemented by using Active Server Pages (ASP), Java Server Pages (JSP), Common Gateway Interface (CGI), or any other Web-server-based framework. The Web interface does not do any significant processing; its purpose is to support user interaction. This is exactly what you intend. Keep the code in ASP or JSP to an absolute minimum to increase the maintainability of your applications. Simply applying an XML schema provides user-input validation. The parser will throw any validation errors in the repackaged XML data.

You have enough information at this point to decide on the contents of the XML message. The XML message used to request the resource calendar view is shown in Listing 26.1.

Listing 26.1. XML Message to Get Resource Calendar

<?xml version="1.0" encoding="utf-8"?> 
<getResourceCalendar> 
       <resource name="bigBuilding"> 
              <range startMonth="1" endMonth="3" startDay="13" 
          endDay="16"/> 
       </resource> 
</getResourceCalendar> 

As you can see, the preceding code is a simple XML message created in the Web Client tier. You can use an XML schema to validate this message. The schema provides the contract you have with the input device. Using this model enables us to support Web-based clients or XML-enabled devices. You can use schemas to open your service to the Internet by creating a Web service.

You need to create the XML schema by using the XML message created in Listing 26.1. You have several ways you could go about creating the XML schema. There are quite a few tools that do a reasonable job; however, no tool can know your business application requirements. Most tools that automatically generate XML schemas produce something similar to the example in Listing 26.2, produced by XML Spy.

Listing 26.2. XML Schema for Resource Calendar Message

<?xml version="1.0" encoding="UTF-8"?> 
<xsd:schema 
targetNamespace= 
  "http://www.XMLSchemaReference.com/examples/CRSS/resourceCalendar" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns= 
  "http://www.XMLSchemaReference.com/examples/CRSS/resourceCalendar" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 
  <xsd:element name="getResourceCalendar"> 
    <xsd:complexType> 
      <xsd:sequence> 
        <xsd:element ref="resource"/> 
      </xsd:sequence> 
    </xsd:complexType> 
  </xsd:element> 
  <xsd:element name="range"> 
    <xsd:complexType> 
      <xsd:attribute name="startMonth" type="xs:int" 
              use="required"/> 
      <xsd:attribute name="endMonth" type="xs:int" 
              use="required"/> 
      <xsd:attribute name="startDay" type="xs:int" 
              use="required"/> 
      <xsd:attribute name="endDay" type="xs:int" 
              use="required"/>   
    </xs:complexType> 
  </xsd:element> 
  <xsd:element name="resource"> 
    <xsd:complexType> 
      <xsd:sequence> 
        <xsd:element ref="range"/> 
      </xsd:sequence> 
      <xsd:attribute name="name" type="xs:string" 
              use="required"/> 
    </xsd:complexType> 
  </xsd:element> 
</xsd:schema> 

Now you have a schema to validate your input message against. You can test this schema by using a plug-in (http://msdn.microsoft.com/downloads) for Internet Explorer that lets you simply right-click on a file and select Validate. You could also use any validating XML parser for this operation. Before you can do any testing, however, you have to associate the XML source with its corresponding schema. You can do that as shown in Listing 26.3.

Listing 26.3. Schema Reference Added to Get Resource Calendar Message

<?xml version="1.0" encoding="utf-8"?> 
<getResourceCalendar 
xmlns= 
 "http://www.XMLSchemaReference.com/examples/CRSS/calendar" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation= 
"http://www.XMLSchemaReference.com/examples/CRSS/calendar.xsd"> 
  <resource name="bigBuilding"> 
    <range startMonth="1" endMonth="3" startDay="13" 
        endDay="16"/> 
  </resource> 
</getResourceCalendar> 

Note the custom namespace on the third line. This is a good practice because namespaces provide scope to XML documents. Listing 26.2 defined the namespace, and you use it within XML documents that will be validated by schemas with the same namespace. More information on namespaces can be found in Chapter 3.

Testing the XML schema is very straightforward. You can use any validating parser to load the document. If the document loads with no errors, the XML message is valid relative to the XML schema. Naturally we must make the assumption that the validating parser does not have errors. There are many tools you can use to provide validation. Some of the popular tools are

• XML Spy by Altova (http://www.xmlspy.com)

• Xerces (http://xml.apache.org/xerces-c/)

• .NET from Microsoft (http://msdn.microsoft.com/vstudio)

• IBM’s parsers (http://www.alphaworks.ibm.com)

When just doing quick tests, the Internet Explorer plug-in is convenient. Microsoft has a download called iexmltls.exe that can be found by following the links at the http://msdn.microsoft.com/xml site. After installing iexmltls.exe you can just add the reference to our XML schema into the XML document and then open the XML document in Internet Explorer. Right-clicking within the document in Internet Explorer provides a menu item to validate. Let’s test our document using this test right now.

Performing validation tests using Internet Explorer’s plug-in is simple, as shown in Figure 26.4 below. You can see that the document is valid. You can make changes to the XML and verify that the XML schema functions as expected. You should test all the permutations possible, so feel free to experiment.

26.1.1. Client Tier Model Revisited

Technically there is certainly nothing wrong with the XML schema generated in Listing 26.2. In fact, the tools do a great job of getting you started. Unfortunately, that’s too often as far as anyone gets with the XML schema design. For XML schemas to provide real power to your projects, you need to take a step back and think about all the datatypes your client application is likely to send. You should then create simple datatypes and include them as needed to create flexible XML schemas. This way you build small, easily tested elements and their corresponding schemas and then aggregate them as needed into a governing document schema on a per document basis.

The following section shows how to

• Identify reusable datatypes

• Create modular XML schemas

• Test modular schemas

• Aggregate the modules into a master XML schema to allow resource reservations

26.1.1.1. XML Schema Support for Reusable Datatypes

Obviously the question is how to modularize your schemas to provide a more productionworthy solution. Fortunately, the Schema Recommendation provides techniques to achieve this modularity. The three techniques are

• include: Used to include other schema documents that have the same target namespace.

• import: Used to refer to components from other namespaces.

• redefine: Similar to include with the additional option that you can provide new definitions for some or all of the types in the redefined schema document.

Below is an example of the include element:

<xsd:include schemaLocation= "mySchemaModule.xsd"/> 

Sometimes you need to override an element definition in an included schema. In objectoriented (OO) programming environments, you would simply inherit from the base class and override the base class’s implementation of a specific method. XML schemas borrow from this popular approach through the use of redefine elements. Listing 26.4 demonstrates the use of redefine. Redefining schemas is useful when you are including large libraries and need to change one or two types. In many cases you will find it more useful to just alter the schema rather than using redefine.

Listing 26.4. Redefining the rangeType Simple Type

<xsd:redefine schemaLocation="mySchemaModule.xsd"> 
<xsd:simpleType name="rangeType"> 
<xsd:restriction base="xsd:string"> 
<xsd:maxLength="30"/> 
</xsd:restriction> 
</xsd:simpleType> 
</xsd:redefine> 

26.1.1.2. Identifying Reusable Datatypes

You know how XML Schema lets you reuse and redefine datatypes. Now you need to determine what reusable simple types you need. Modeling each message by using the UML techniques discussed in this chapter identifies your application’s required datatypes. The complete design processes required to properly model the application are beyond the scope of this book; however, we do review the sequence diagram you will use to create the XML schema.

You use the desired reservation request XML message to identify the datatypes you would like to create. This approach lets us focus on the XML Schema techniques and illustrate how to create reusable XML schemas. Typically, you start with the UML sequence diagram and then create a sample XML message representing the data required to accomplish the task. The sequence diagram for reserving a resource is shown in Figure 26.5.

In a real system, the sequence diagram would have far more complexity. For our CRSS application, a simple diagram illustrates how the diagrams can assist in creating XML schemas.

Using the sequence diagram in Figure 26.5, you can create a sample XML message that assists in determining the data required to satisfy the request. The sample is in Listing 26.5.

Listing 26.5. Reservation Request XML Message

<?xml version="1.0" encoding="utf-8"?> 
<reservation_request> 
  <reservation building="Linden Hall" room="Gymnasium" 
         start_date="2001-02-23" 
         start_time="22:30:00" 
         duration="5" 
         description="Varsity basketball practice" 
         configuration="basketball"/> 
  <security> 
    <requestor first="Paul" 
          last="Lamere" 
          email="[email protected]" 
          type="coach"/> 
  </security> 
  <building id="1" name="Linden Hall" 
       location="images/linden.gif"> 
    <room name="Gymnasium" capacity="100"> 
      <form id="201" name="legal" 
         url="forms/legal.html"/> 
      <form id="202" name="rental_contract" 
         url="forms/rental.html"/> 
      <form id="203" name="cost_contract" 
         url="forms/costContract.html"/> 
      <resource_owner first="Ed" last="Agenda" 
              email="[email protected]" 
              type="administration"/> 
    </room> 
  </building> 
  <workflow> 
    <request view="xslt/request.xslt" status="false"/> 
    <approval view="xslt/approval.xslt" status="false"/> 
    <viewCalendar view="xslt/viewCalendar.xslt" 
           status="false"/> 
    <viewPending view="xslt/viewPending.xslt" 
           status="false"/> 
  </workflow> 
</reservation_request> 

The reservation request shown in Figure 26.5 can be broken down into several important steps. The reservation element contains the information a user is going to provide by using a browser or some other Web interface device. The ‘security’ element is used to attach security information to the incoming message. The workflow element is used to track the status of the reservation request. The building element contains response data that will be sent to the user with room capacity information, required forms, the room’s contact person and more. The application will fill in the user’s security information, supply the user with the required forms to fill in, and keep track of the user’s status in completing the workflow.

Let’s use the message in Listing 26.6 to create a matrix of datatypes and the constraints we would like to apply. The matrix information in Table 26.1 is a reasonable start.

You can see in Table 26.1 that each XML message has a number of datatypes and desired constraints. Several of these datatypes will be very reusable on many messages. Specifically, constraints on user’s names, e-mail formatting, date, time, and status will be usable across many XML schemas. You always want to achieve the highest reusable rate from your work. Developing many small XML schemas that can be tested independently and then included in your project will help achieve the goal of reusability.

26.1.1.3. Creating XML Schema Reusable Datatypes

You should identify the datatypes you think will be reusable in this and future applications from those in Table 26.1. Many datatypes can be reused frequently.

Start by creating an XML Schema simple type to model start_date. The Schema Recommendation has a date datatype as one of the primitive datatypes. The CRSS application needs to be restricted to allow reservation requests to be placed only between 2001 and 2099. In a production application you might not want to create a Y2.1K problem, but you will in the CRSS application to demonstrate XML Schema restrictions.

Creating a simple type to constrain the attribute date can be done as shown in Figure 26.2. Notice that a pattern is used to constrain the value range and the format that the date must be submitted in. If you just needed to constrain the values to range, the minInclusive and maxInclusive constraints could have been applied.

Listing 26.6. CRSS Start Date Constrained

 <?xml version="1.0" encoding="utf-8" ?> 
<xsd:schema id="dateType" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<xsd:annotation> 
  <xsd:documentation> 
    Format date range to CCYY-MM-DD w/range 2001_to 2009 
  </xsd:documentation>  
 </xsd:annotation> 
 <xsd:simpleType name="dateType"> 
 <xsd:restriction base="xsd:date"> 
 <xsd:pattern 
   value="([2][0][0][1-9])-((0[1-9])|(1[0-2]))-d{1,31}"/> 
 </xsd:restriction> 
</xsd:simpleType> 
</xsd:schema> 

Documenting your XML schemas is always a good idea. The restriction element specifies that the base datatype you will derive from is the XML Schema date. The next line derives a new date type by adding additional restrictions. You have chosen to name the newly derived type ‘dateType’. The new dateType datatype has all the properties of the XML Schema date datatype and our additional restrictions.

The pattern value must be an XML Schema regular expression. For more information, refer to Chapter 14.

Now that you have created a simple datatype, dateType, the question is how to test it. One technique is to create another XML schema with a very simple structure and just use the XML Schema include element to reference the datatype you have created. In the test case in Listing 26.7, a test XML schema is created that has a root element named root with one additional element called test. The test element takes one attribute, dateTest, which uses our new dateType. Listing 26.7 is the test case.

Listing 26.7. Schema for Testing dateType

1. <?xml version="1.0" encoding="utf-8" ?> 
2. <xsd:schema id="dateTypeTest" elementFormDefault="qualified" 
3. targetNamespace="http://www.XMLSchemaReference.com/ 
4.           examples/CRSS/dateTypeTest.xsd" 
5. xmlns="http://www.XMLSchemaReference.com/ 
6.           examples/CRSS/dateTypeTest.xsd" 
7. xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
8. <xsd:include schemaLocation="dateType.xsd" /> 
9. <xsd:element name="root"> 
     <xsd:complexType> 
       <xsd:sequence minOccurs="1" maxOccurs="1"> 
         <xsd:element name="test"> 
           <xsd:complexType> 
             <xsd:attribute name="dateTest" 
                     type="dateType"/> 
           </xsd:complexType> 
         </xsd:element> 
       </xsd:sequence>   
   </xsd:complexType> 
  </xsd:element> 
</xsd:schema> 

The include element in Listing 26.7 includes our new dateType simple type. The dateTest attribute uses the custom datatype that you defined. You need to test this by creating a XML document that adheres to the XML schema in Listing 26.7 and then validating by using one of any number of tools. For our purposes, use Microsoft’s .NET Framework to perform the test. If you do not have Visual Studio .NET then use the validation plug-in for Internet Explorer mentioned earlier.

Use any text editor to create the code shown in Listing 26.8. This listing references the dateTypeTest schema that includes the dateType simple type created first. This provides a very simple test to verify that the simple type is correct.

Listing 26.8. XML Test Case for dateType Simple Type

1. <?xml version="1.0" encoding="utf-8" ?> 
2. <root xmlns="http://www.XMLSchemaReference.com/examples/CRSS/dateTypeTest.xsd"> 
3. <test dateTest="2001-02-26"/> 
4. </root> 

You can experiment with the XML document in Listing 26.8 and verify that your new dateType XML schema is working. Changing the dateTest attribute in Listing 26.8 to 2000-02-26 results in an error in the .NET Framework, as shown in Figure 26.6.

Testing the schema in .NET is simple. Add the listings shown in Listings 26.6, 26.7, and 26.8. Next, open the file containing Listing 26.8. Then open the XML menu and choose Validate. Note the status messages displayed in the output pane of the .NET windows.

Just to be thorough, also test the dateType by using XML Spy. With XML Spy, you can use whatever validating parser you prefer. Using XML Spy, simply load your XML document and assign the desired schema to validate with. XML Spy displays errors if your XML source violates the governing schema’s rules, as shown in Figure 26.7.

The failed result in Figure 26.7 is not due to the XML schema date format. The 2000-12-31 format works well with the XML schema primitive date datatype. The pattern you used constrained the date range to the years 2001 through 2099. Properly restricting your datatypes by using XML Schema facets reduces the amount of validation code typically required by the application.

26.1.1.4. Reusable Datatype Review

This is a good point to review what we’ve done so far in creating reusable datatypes. The process is outlined below:

There are many different ways to restrict data by using XML schemas. You have seen several examples in previous chapters of the book. The CRSS application XML schemas restrict the data by using many XML Schema techniques, including the following:

• pattern: Entries must match the pattern specified

• minOccurs: Minimum number of repetitions allowed

• maxOccurs: Maximum number of repetitions allowed

• minLength: Minimum string length

• enumeration: List of allowed entries

• minInclusive: Minimum integer value allowed

• maxInclusive: Maximum integer value allowed

Each XML simple type will not be reviewed in detail. The final code listing for our reservation request is in Listing 26.9. Listing 26.9 can be applied to Listing 26.7 to provide validation to the completed reservation request.

Listing 26.9. XML Schema for Completed Reservation Request

<?xml version="1.0" encoding="utf-8" ?> 
<xsd:schema id="resRequest" elementFormDefault="qualified" 
targetNamespace= 
"http://www.XMLSchemaReference.com/examples/CRSS" 
xmlns="http://XMLSchemaReference.com/examples/CRSS" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<xsd:include schemaLocation="dateType.xsd"/> 
<xsd:include schemaLocation="buildingType.xsd" /> 
<xsd:include schemaLocation="roomType.xsd" /> 
<xsd:include schemaLocation="configType.xsd" /> 
<xsd:include schemaLocation="durationType.xsd" /> 
<xsd:include schemaLocation="emailType.xsd" /> 
<xsd:include schemaLocation="requestorType.xsd" /> 
<xsd:include schemaLocation="locationType.xsd" /> 
<xsd:include schemaLocation="nameType.xsd" /> 
<xsd:include schemaLocation="urlFormType.xsd" /> 
<xsd:element name="reservation_request"> 
  <xsd:complexType> 
    <xsd:sequence minOccurs="1" maxOccurs="1"> 
      <xsd:element name="reservation" minOccurs="1"  
         maxOccurs="1"> 
  <xsd:complexType> 
    <xsd:attribute name="building" use="required" 
            type="buildingType" /> 
    <xsd:attribute name="room" use="required" 
            type="roomType" /> 
    <xsd:attribute name="start_date" 
            use="required" 
            type="dateType" /> 
    <xsd:attribute name="start_time" 
            use="required" 
            type="xs:time" /> 
    <xsd:attribute name="duration" 
            use="required" 
            type="durationType" /> 
    <xsd:attribute name="description" 
            use="required" 
            type="xs:string" /> 
    <xsd:attribute name="configuration" 
            use="required" 
            type="configType" /> 
  </xsd:complexType> 
  </xsd:element> 
  <xsd:element name="security"> 
  <xsd:complexType> 
    <xsd:sequence minOccurs="1" maxOccurs="1"> 
      <xsd:element name="requestor"> 
      <xsd:complexType> 
      <xsd:attributeGroup ref="userAttGroup"/> 
      </xsd:complexType> 
      </xsd:element> 
    </xsd:sequence> 
  </xsd:complexType> 
  </xsd:element> 
  <xsd:element name="building"> 
  <xsd:complexType> 
    <xsd:sequence minOccurs="1" maxOccurs="1"> 
      <xsd:element name="room"> 
      <xsd:complexType> 
      <xsd:sequence> 
        <xsd:element name="form" 
               minOccurs="0" 
               maxOccurs="unbounded"> 
      <xsd:complexType> 
      <xsd:attribute name="id" use="required" 
              type="xs:int" />   
      <xsd:attribute name="name" use="required" 
              type="nameType" /> 
      <xsd:attribute name="urlForm" 
              use="optional" 
              type="urlFormType"/> 
      </xsd:complexType> 
      </xsd:element> 
      <xsd:element name="resource_ 
             owner" minOccurs="1" 
             maxOccurs="2"> 
      <xsd:complexType> 
       <xsd:attributeGroup ref="userAttGroup"/> 
      </xsd:complexType> 
      </xsd:element> 
      </xsd:sequence> 
      <xsd:attribute use="required" name="name" 
             type="nameType"/> 
      <xsd:attribute use="required" 
             name="capacity"> 
        <xsd:simpleType id="capLimits"> 
        <xsd:restriction base="xs:int"> 
          <xsd:minInclusive value="5"/> 
          <xsd:maxInclusive value="200"/> 
        </xsd:restriction> 
        </xsd:simpleType> 
      </xsd:attribute> 
      </xsd:complexType> 
      </xsd:element> 
    </xsd:sequence> 
    <xsd:attribute name="id" use="required" 
            type="xs:int" /> 
    <xsd:attribute name="name" use="required" 
            type="nameType" /> 
    <xsd:attribute name="location" use="required" 
    type="locationType" /> 
    </xsd:complexType> 
   </xsd:element> 
   <xsd:element name="workflow"> 
   <xsd:complexType> 
     <xsd:sequence> 
       <xsd:element name="workFlowItem" 
             minOccurs="1" 
             maxOccurs="10"> 
       <xsd:complexType> 
       <xsd:sequence /> 
       <xsd:attribute name="action" 
              use="required">  
          <xsd:simpleType> 
           <xsd:restriction base="xs:string"> 
            <xsd:enumeration value="request"/> 
            <xsd:enumeration value="approval"/> 
            <xsd:enumeration 
              value="viewCalendar"/> 
            <xsd:enumeration 
              value="viewPendingRequests"/> 
           </xsd:restriction> 
          </xsd:simpleType> 
          </xsd:attribute> 
          <xsd:attribute name="view"> 
          <xsd:simpleType> 
           <xsd:restriction base="xs:string"> 
            <xsd:enumeration 
              value="xslt/request.xslt"/> 
            <xsd:enumeration 
              value="xslt/approval.xslt"/> 
            <xsd:enumeration 
              value="xslt/viewCalendar.xslt"/> 
            <xsd:enumeration 
              value="xslt/viewPending.xslt"/> 
           </xsd:restriction> 
          </xsd:simpleType> 
          </xsd:attribute> 
          <xsd:attribute name="status" 
                 type="xs:boolean"/> 
          </xsd:complexType> 
          </xsd:element> 
        </xsd:sequence> 
       </xsd:complexType> 
       </xsd:element> 
    </xsd:sequence> 
  </xsd:complexType> 
</xsd:element> 
<xsd:attributeGroup name="userAttGroup"> 
<xsd:attribute name="first" type="nameType" use="required"/> 
<xsd:attribute name="last" type="nameType" use="required"/> 
<xsd:attribute name="email" type="emailType" use="required"/> 
<xsd:attribute name="type" type="requestorType" 
        use="required"/> 
</xsd:attributeGroup> 
</xsd:schema> 

You can see from the preceding code listing that we have achieved a modular XML schema. The xsd:include elements reference simple XML schemas that have been created and tested independently. The userAttGroup element near the end of the listing creates a named attribute group that includes the first, last, email, and type attributes. Named attribute groups maximize reuse by consolidating the definition of a group of frequently occurring attributes. The final XML schema is an aggregation of the various modules. This expedites future XML schema developments.

You need to test the final XML schema to verify that the conformant XML documents match your expectations. Fortunately, tools can assist quite a bit in this area. XML Spy has an option for generating an XML sample document from the XML schema. Listing 26.10 shows an output from XML Spy, using its sample document facility.

Listing 26.10. XML Spy Auto-Generated Sample XML

 <?xml version="1.0" encoding="UTF-8"?> 
 <!-- generated by XML Spy v4.0.1 U (http://www.xmlspy.com)--> 
 <reservation_request 
 xmlns="http://XMLSchemaReference.com/examples/resRequest.xsd" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation= 
 "http://XMLSchemaReference.com/examples/CRSS/resRequest.xsd"> 
<reservation building="Library" room="class room" 
       start_date="2001-01-01" 
       start_time="00:00:00" duration="8" 
       description="String" configuration="lecture"/> 
  <security> 
    <requestor first="abc" last="abc" email="[email protected]" 
          type="student"/> 
  </security> 
  <building id="0" name="a" location="images/a.gif"> 
    <room name="a" capacity="200"> 
      <form id="0" name="abc" urlForm="forms/a.html"/> 
      <form id="0" name="abc" urlForm="forms/a.html"/> 
      <form id="0" name="abc" urlForm="forms/a.html"/> 
      <form id="0" name="abc" urlForm="forms/a.html"/> 
      <form id="0" name="abc" urlForm="forms/a.html"/> 
      <resource_owner first="abc" last="abc" 
          email="[email protected]" type="administration"/> 
    </room> 
  </building> 
  <workflow> 
    <workFlowItem action="request" 
           view="xslt/request.xslt" status="1"/> 
    <workFlowItem action="request" 
           view="xslt/request.xslt" status="1"/> 
    <workFlowItem action="request" 
           view="xslt/request.xslt" status="1"/> 
    <workFlowItem action="request" 
           view="xslt/request.xslt" status="1"/>  
    <workFlowItem action="request" 
           view="xslt/request.xslt" status="1"/> 
  </workflow> 
</reservation_request> 

XML Spy’s automatically generated XML document provides an easy way to identify problems with your schema. If you are satisfied with the output, you can continue. If other constraints are needed, you should continue working with the XML schema until you are satisfied.