Document Classes

By declaring that a document matches a specific type, authors are able to create documents that fall into a certain category, or class. The concept of classing is drawn from the programming world—specifically, object-oriented programming. You need to take a look at some of the concepts and features of object-oriented design before you'll see how they apply to XML documents.

Reusable objects are self-contained items that can be used independently but are usually employed in conjunction with other objects or programs. Most objects are designed to be used for a specific purpose; they have their own properties and perform particular actions (called methods). Objects also have some common features and characteristics that make them especially powerful and flexible programming aids. If you're familiar with object-oriented programming, you might have heard of the terms inheritance, polymorphism, and encapsulation. With regard to XML document classes, the concepts of inheritance and polymorphism are particularly important.

Inheritance in programming is based loosely on the idea of familial inheritance: via familial genetic inheritance, a person carries some of the same family traits as a parent. Object-oriented programming works in a similar way. A programmer can create an object that contains all of the characteristics and properties of a "parent" object. The new "child" object inherits these characteristics from the parent object. The programmer can then modify some of the new object's characteristics or even add to them to create a completely separate object with individual characteristics.

At this point, the concept of classes enters the picture. The original parent object is called the base class—the object upon which other objects will be based. Subsequent child objects are called subclasses of the base class. Programmers can create as many subclasses as they want and can even subclass a subclass! This beneficial approach allows the programmer to use most or all of the necessary features and functions of an object and then modify them to suit particular needs. Using object classes not only saves programmers a tremendous amount of repetitive programming, but it makes programs more consistent and saves testing time because the base object never changes.

Here's an example. Let's say you wrote a program object called Book. This object had the properties NumberOfChapters and CoverColor. The Book object represents the base class upon which you will base all subsequent Book subclasses. Now you are going to create two subclasses: CookBook and TextBook. In the new CookBook object, you specify that the NumberOfChapters property equals 10, and in the new TextBook object, the NumberOfChapters property equals 21. The CoverColor property for CookBook is Red, and the CoverColor property for TextBook is Blue. Next you add a property to CookBook called Recipe and a property to TextBook called Glossary. You now have created two objects based on a single base class, and each contains additional properties to suit specific purposes. The NumberOfChapters and CoverColor properties are inherited directly from the base class Book and are available to any subclassed object. The class hierarchy for this example is shown in Figure 4-1.

Figure 4-1. The Book base class and its subclasses.

Through polymorphism, the characteristics of a derivative object can be modified to perform different functions, thereby overriding the characteristics of the base class. Consider the Book example. Suppose you want to create a subclass called ArtBook. But instead of the CoverColor property being able to accept only colors, you want the property to be able to specify the names of patterns—you want your ArtBook object's CoverColor property to be equal to PolkaDots. In this case, the CoverColor property from the base class is overridden with a modified property of the same name. This explains the concept of polymorphism.

Inheritance and polymorphism carry over into the XML world as well—but in concept only, as you'll see. Consider the XML code example used in the last chapter:

<?xml version="1.0"?>
<!DOCTYPE Wildflowers SYSTEM "Wldflr.dtd">

<PLANT>
  <COMMON>Columbine</COMMON>
  <BOTANICAL>Aquilegia canadensis</BOTANICAL>
</PLANT>

This code declares the document type as Wildflowers and tells the XML processor that the document should follow the rules found in the file Wldflr.dtd. In XML programming, as in object-oriented programming, you can create child documents that inherit the rules of the parent document, even though the children might include completely different content. You can also modify the rules in a child XML document to suit particular needs; this concept corresponds to the notion of polymorphism. The piece that makes all of this possible is the second part of the document type declaration, the DTD.