What Can Object-Oriented Development Techniques Do for DTD Development?

An understanding of the parallels between object-oriented and SGML development lets SGML application developers take advantage of a great deal of existing research (and, in the future, development tools) that can speed their application development.

One important concept of object-oriented development, and another key to the object-oriented developers’ claims of greater productivity, is the notion of design re-use in addition to code re-use. While traditional structured design encourages code reuse through the development of functions and procedures that can be called in a variety of situations, the object-oriented approach puts greater emphasis on the analysis and design stages so that the information gathered can be re-used in these crucial early stages of future application development. The analysis and design already done for the SGML developer result in the creation of a DTD, which specifies a large majority of the information an object-oriented developer needs to know to quickly create an application.

Most of the goals and even methods of DTD design have much in common with those of object-oriented analysis and design. For a developer using SGML data, the existence of a good DTD means that the majority of the analysis and design has already been done and stored in a clearly defined notation that a program can easily parse and use to declare classes in an object-oriented system. Analysis of typical SGML systems reveals more aspects that can be automated, reducing the developer’s work even further.

What if a DTD doesn’t exist, and the SGML developer is working from the ground up? While current SGML literature offers little on DTD development, object-oriented literature has much to say about analysis and design that can benefit the DTD developer. The tasks described in this literature are the tasks that the DTD developer must take on; for example, Booch writes that “By studying the problem’s requirements and/or by engaging in discussions with domain experts, the developer must learn the vocabulary of the problem domain. The tangible things in the problem domain, the roles they play, and the events that may occur form the candidate classes and objects of our design, at its highest level of abstraction.”

DTD developers must become familiar with different roles of document elements in different output formats as well as the development and production process of publishing systems ranging from elementary school textbooks to nuclear reactor installation manuals. They also face problems similar to those of the object-oriented systems developer. For example, Rumbaugh writes that “In modeling an engineering problem, the object model should contain terms familiar to engineers; in modeling a business problem, terms from the business; in modeling a user interface, terms from the application domain.” The DTD designer and the object-oriented system designer must both learn the language of their clients and the principles underlying the language so that they can understand exactly what the application needs.

Like Rumbaugh’s designer, the DTD designer must work to get beyond the terminology, which can be misleading. Publishing professionals are worse than computing professionals in applying terms to concepts long after the concept has evolved to lose all relation to the term; perhaps the most well-known example is the still-common use of the term “leading” (pronounced “ledding”) to describe the amount of space between printed lines because this was once done with the insertion of small pieces of lead between lines of type. A less picturesque example is the tendency by page layout people to think of the terms “emphasize” and “italicize” as synonymous, which causes problems in output media that allow emphasis but not italics. The SGML goal of separating structure from behavior (which, at the simplest level, means separating structure from appearance) is precisely what gives the object-oriented developer such a wide range of ways to use the data.

As an example of how the object-oriented emphasis on analysis could make for a better DTD, consider a multi-volume encyclopedia that has been published in hard-copy books and is being converted to SGML for easier production as an online hypertext version. Each volume has several chapters that contain the entries for a letter of the alphabet. Here is a simplified DTD:

     <!DOCTYPE ency [
     <!ELEMENT ency    o o (volume+)>
     <!ELEMENT volume  o o (section+)>
     <!ELEMENT chapter - o (title,entry+)>
     <!ELEMENT entry   - o (title,para+)>
     <!ELEMENT title o o (#PCDATA)>
     <!ELEMENT para    - o (#PCDATA)>
     ]>

Following all the steps of a formal analysis might show that each volume had no special attributes to distinguish itself from other volumes. In fact, the only reason that the encyclopedia wasn’t published as one big 8,000 page book is the impracticality of binding such a book. This analysis of the publication’s information shows that the assumption that “volume” was an intrinsic part of the structure is unnecessary. We can then reduce a level of complexity in the encyclopedia’s structure by removing that element and specifying that an encyclopedia is made of a collection of chapters, not volumes:

     <!DOCTYPE ency [
     <!ELEMENT ency    o o (chapter+)>
     <!ELEMENT chapter - o (title,entry+)>
     <!ELEMENT entry   - o (title,para+)>
     <!ELEMENT title o o (#PCDATA)>
     <!ELEMENT para    - o (#PCDATA)>
     ]>

There is nothing particularly object-oriented about this design decision (although it has even less relation to relational design, in which you have to figure out how to squeeze everything into tables). No DTD is more object-oriented than any other; the key is that the process of creating a DTD has enough in common with object-oriented analysis and design that the ample OOA/OOD literature available provides a great resource for a DTD designer looking for help in DTD creation—especially considering the current lack of material on DTD development in the SGML literature. The object-oriented belief that more attention to the OOA/OOD stages decreases the implementation work leads to object-oriented methodologies with extensive, detailed advice on system analysis and design.