Working with XML Schemas

In the preceding section, we went into great depth about what DTDs are and how to create them, but we finished up commenting on DTDs' deficiencies and discussed the creation of the XML Schema language.

In this section, we will not go into such depth and will instead suggest that you go to www.w3.org/XML/Schema or read New Riders' Inside XML by Steve Holzner to get more specific, in-depth information on XML Schemes. What we are going to do in this section is build on your knowledge of DTDs, compare them to XML Schema, and give you enough information that you understand why and how to use XML Schemes. If you need more information, we'll show you where to go get it.

Before we get into XML Schema, let's just recap a few concepts that make DTDs difficult to use or deficient for some purposes:

• DTDs use an awkward syntax that is different from the syntax of XML documents. This requires you to learn another notation as well as XML software to have a DTD parser to validate XML.

• There is no way to specify data types and data formats that could be used to automatically map to and from programming languages.

• There is not a set of well-known basic elements to choose from.

• DTDs were inherited by XML from its predecessor, SGML, and were a good way to get XML started off quickly and to give SGML people something familiar to work with. Nevertheless, it soon became apparent that a more expressive solution was needed that used itself XML.

Defining Elements

Defining an element specifies its name and content model, meaning attributes and nested elements. In XML Schemas, the content model of elements is defined by their type. An XML document adhering to a schema can then only have elements that match the defined types. You must also distinguish between simple and complex types.

A number of simple types are predefined in the specification, such as string, integer, and decimal. A simple type cannot contain elements or attributes in its values, whereas complex types can specify nesting of elements and associations of attributes with an element.

A simple example could look like this:

 <element name="quantity" type="positive-integer"/>  <element name="amount" type="decimal"/> 

User-defined elements can be formed from the predefined ones using the object-oriented concepts of aggregation and inheritance. Aggregation groups a set of existing elements into a new one. Inheritance extends an already-defined element so that it can stand in for the original.

Defining values like <value unit="Celsius">42</value> derived from decimals would look something like this:

 <element name="value">  <complexType base='decimal' derivedBy='extension'>  <attribute name='unit' type='string'/>  </complexType>  </element> 

Aggregating time and value into a measurement would look like this:

 <measurement>  <time>2000-10-08 12:00:00 GMT<time/>  <value unit="Celsius">42</value>  </measurement> 

Here is what the resulting schema definition would look like:

 <element name='measurement' type='measurement'/>  <complexType name='measurement'>  <element name='time' type='time'/>  <element name='value' type='value'/>  </complexType> 

Now, if we did the same thing with a DTD, it would look something like this:

 <!ELEMENT measurement (time, value)>  <!ELEMENT time (#PCDATA)>  <!ELEMENT value (#PCDATA)>  <!ATTLIST value (unit)> 

One very cool thing about XML Schema is the concept of inheritance, which you will find in any object-oriented-based language such as Java (and now in CFML in CFCs!). Much like in Java, for example, you can declare a class as "abstract" to force an inherited implementation or declare a class as "final" to prevent subclassing. This way, a one-to-one mapping between an element definition and a Java (or C++ and so on) class becomes possible. This becomes important when you are trying to tie your document to actual objects or code. A specific example would be the way in which many vendors are approaching mapping web services to specific objects or code the XML description document that descibes the services offered from a specific system even maps to the actual objects that do the work.

Expressing Cardinalities of Elements

XML Schema has more possibilities than DTD for expressing cardinalities on the elements of a document type. In DTD, you indicate that a sequence of one only (1), zero or more (*), or one or more (+) elements from a given set can occur. XML Schema uses the minOccurs and maxOccurs attributes to define cardinalities:

 <element ref="optionalElement" minOccurs="0"/>  <element ref="twoOrMoreElements" minOccurs="2" maxOccurs="unbounded"/>  <element ref="exactlyOneElement" /> 

The default values for minOccurs and maxOccurs are 1. Another possibility is to use the choice and all elements. The element choice allows only one of its children to appear in an instance, whereas all defines that all child elements in the group can appear at most once in any order. Such constraints are very difficult and awkward to try to create in a DTD.

For example:

 <xsd:choice>  <element ref="EitherThis"/>  <element ref="OrThat"/>  </xsd:choice>  <xsd:all>  <element ref="positive"/>  <element ref="negative"/>  </xsd:all/>  

Namespaces

An XML Schema definition specifies one vocabulary, the target namespace, possibly using other vocabularies by including them through the use of namespaces:

 <xsd:schema targetNamespace='http://www.physics.com/measurements'  xmlns:xsd='http://www.w3.org/1999/XMLSchema' xmlns:units=  'http://www.physics.com/units'>  <xsd:element name='units' type='units:Units'/>  <xsd:element name='measurement' type='measurement'/>  <complexType name='measurement'>  <element name='time' type='time'/>  <element name='value' type='value'/>  </complexType> 

This mechanism offers the modularity and extensibility needed to build up a grand hierarchy of namespaces, from basic things like addresses to very specific objects in any subject matter.

Comparison

Now let's take another quick look at our DTD for a price list and then compare it to an XML Schema (see Listing 19.3).

Listing 19.3 Pricelist.DTD

 <?xml version="1.0" encoding="UTF-8"?>  <!  ********************************************************  >  <!  VSI Pricelist file Definition                     >  <!  ********************************************************  >  <!ELEMENT price-list (price-group*)>  <!ELEMENT price-group (name, price-element*)>  <!ELEMENT price-element (product-code, description, license*, list-price)>  <!ELEMENT license (quantity | unlimited)>  <!ATTLIST license        type (Server | Clients | WebServer | FaxServer) "Server"  >  <!ELEMENT name (#PCDATA)>  <!ELEMENT product-code (#PCDATA)>  <!ELEMENT description (#PCDATA)>  <!ELEMENT list-price (#PCDATA)>  <!ELEMENT quantity (#PCDATA)>  <!ELEMENT unlimited (#PCDATA)> 

Now let's look at the same thing as an XML Schema (see Listing 19.4).

Listing 19.4 Pricelistschema.xsd

 <?xml version="1.0" encoding="UTF-8"?>  <! W3C Schema generated by XML Spy v4.2 U (http://www.xmlspy.com) >  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">        <xs:element name="description" type="xs:string"/>        <xs:element name="license">              <xs:complexType>                    <xs:choice>                          <xs:element ref="quantity"/>                          <xs:element ref="unlimited"/>                    </xs:choice>                     <xs:attribute name="type" default="Server">                          <xs:simpleType>                                <xs:restriction base="xs:NMTOKEN">                                      <xs:enumeration value="Server"/>                                      <xs:enumeration value="Clients"/>                                      <xs:enumeration value="WebServer"/>                                      <xs:enumeration value="FaxServer"/>                                </xs:restriction>                          </xs:simpleType>                    </xs:attribute>              </xs:complexType>  </xs:element>  <xs:element name="list-price" type="xs:string"/>  <xs:element name="name" type="xs:string"/>  <xs:element name="price-element">                <xs:complexType>                    <xs:sequence>                          <xs:element ref="product-code"/>                          <xs:element ref="description"/>                          <xs:element ref="license" minOccurs="0" maxOccurs="unbounded"/>                          <xs:element ref="list-price"/>                    </xs:sequence>              </xs:complexType>        </xs:element>        <xs:element name="price-group">              <xs:complexType>                    <xs:sequence>                          <xs:element ref="name"/>                          <xs:element ref="price-element" minOccurs="0"  maxOccurs="unbounded"/>                    </xs:sequence>              </xs:complexType>        </xs:element>        <xs:element name="price-list">              <xs:complexType>                    <xs:sequence>                          <xs:element ref="price-group" minOccurs="0" maxOccurs="unbounded"/ >                    </xs:sequence>              </xs:complexType>        </xs:element>        <xs:element name="product-code" type="xs:string"/>        <xs:element name="quantity" type="xs:string"/>        <xs:element name="unlimited" type="xs:string"/>  </xs:schema>  

Wrapping Up

XML Schema offers a rich and flexible mechanism for defining XML vocabularies. It promises the next level of interoperability by describing meta-information about XML in XML. Various tools for validating and editing schemas are available from the Apache Project, IBM alphaWorks, and of course, Microsoft. It's important to reenforce that DTDs have not been replaced by XML Schema and that most XML-enabled applications use DTDs as well as most trading partners and content syndication systems that you might work with. However, XML Schema will gradually become the dominant method for creating XML metadata.

Note

ColdFusion does not support the validation of XML documents. If you want to validate your XML documents, you need to directly call an XML parser that supports validation via CFOBJECT or CFX.