| Previous | Table of Contents | Next |
What benefits can SGML provide to the object-oriented developer, and more importantly, what benefits can object-oriented technology provide to the SGML application developer?
If you take advantage of object-oriented techniques to develop SGML applications, don’t give in to the temptation to coin some horrid new acronym like “OOSGML,” because one key aspect of object-oriented systems is diametrically opposed to a key aspect of SGML.
An intrinsic part of an object-oriented system is the specification of object behavior. On the other hand, good SGML design specifies only object structure, intentionally excluding the behavior of “objects” (the document and its component elements) as much as possible to give the most flexibility to developers using that data.
Caution:
Don’t give in to the temptation to call SGML “naturally object-oriented.” A lot of common ground between SGML and object-oriented systems can help the developer, but SGML objects need behavior defined for them before you can consider them object-oriented.
So if the key difference between SGML and object-oriented systems is that the former doesn’t specify behavior for its “objects,” then at the simplest level, defining some behavior for these objects should turn it into an object-oriented system. You can actually think of all SGML application development—the process of creating a useful application around a given DTD and its document instances—as adding behavior to SGML data, whether or not you take an object-oriented approach.
While examining the common ground between object-oriented systems and SGML, your two primary goals are:
Using the official ISO 8879 standard that defines SGML and Charles Goldfarb’s commentary on it, along with the seminal works on object-oriented development by Grady Booch and James Rumbaugh, let’s compare the definitions of key object-oriented and SGML terms to lay the groundwork for a discussion of what they have in common.
• See “Books on SGML,” p. 565
The most important terms in object-oriented systems are class, instance, attributes, state, and behavior. The first three, in particular, will be familiar to SGML developers.
In the object-oriented world, a class is a group of objects with similar properties, and an instance is a specific object, or member of a class. While the SGML use of these words is more limited, the terms document type and element type make up for this limitation. Comparing their definitions with the object-oriented concept of class shows how SGML documents and their components can be treated as objects, or, in object-oriented terms, as instantiations of predefined classes.
Section 4.102 of ISO 8879 defines a document type as “a class of documents having similar characteristics; for example, journal, article, technical manual, or memo.” Later, it defines an element type as “a class of elements having similar characteristics.” Neither definition mentions how a DTD, when specifying a document’s elements and their legal arrangements, defines the structural relationships among a document’s elements. This and SGML’s use of the term “attributes” to identify element characteristics makes document and element types very close to the object-oriented concept of a “class” of objects. In the section “A Sample Smalltalk SGML System,” later in this chapter, you’ll see a Smalltalk application that does just that.
Remember, however, that SGML element classes still lack one key feature to make them proper object-oriented classes: definition of object (that is, element) behavior.
According to Rumbaugh, a class “describes a possibly infinite set of objects. Each object is said to be an instance of its class. Each instance of the class has its own value for each attribute, but shares the attribute names and operations with other objects of the class.” A DTD’s declaration of a chapter describes a possibly infinite number of chapters, which each have the same attribute names (for example, RevisionDate or an ID used for hypertext links to the chapter) but different values (or even the same values, as with two chapters that were revised the same day) for those attributes.
SGML uses the term instance, but only when referring to a document, not its component elements. There’s nothing about the document’s status as a special kind of element to prevent you from using the document term “instance” to apply to other SGML elements in addition to documents. Since documents are merely a special case of elements—in fact, an element like a chapter can be the document in one context, but a component of a larger document in another—you can treat specific examples of a particular element class as instances as well.
| Previous | Table of Contents | Next |