Element Occurrence

As you examine the occurrence of elements in a document, you know that certain elements are present more than once. In this book, for example, the chapter element occurs many times. Other elements occur only once, as in the case of a title page. Still other elements, such as a section reference, might or might not occur within a chapter.

Consider this in terms of your trip to Albuquerque. You are planning the trip. You want to sketch out the tasks along the way. You know that you must fill the gas tank several times, but you are not sure how many fill-ups will be needed. You are not sure whether you will need to change the oil on the trip. If you do, you will get it done when you get to Albuquerque. After you arrive in Albuquerque, you might have a few big dinners. Now you can diagram your trip in this way:

  Trip = (Fill Tank,Leave San Diego,Fill Tank+,Arrive
  Albuquerque,(Oil Change?&Big Dinners*)

This notation indicates that you will fill the gas tank, leave San Diego, fill the gas tank at least once more, and arrive in Albuquerque. After arriving, you might change the oil once, or you might not. You also might go out for one or more big dinners.

Table 8.2 describes the structure notation for occurrence that you have just used in modeling this trip.

This notation is also useful in describing the contents of this book. For example, you would define the chapters as chapter+ because you know that there is at least one of them. You would define the title page as title page, with no symbolic notation, because there is only one title page. You would define the section references as section reference* because each section might or might not have one or more of them.

You now have a way to specify both the sequence and the frequency of elements. Now take a look at how you can specify the hierarchy of elements.

Element Hierarchy

As you have seen, you can define your trip to Albuquerque in several different ways. You first looked at it in terms of the legs of the trip. You next defined it in terms of the places you will visit along the way. Finally, you considered the trip in terms of servicing—for your car and yourself.

In all these examples, the trip consists of various elements that make up the whole journey. When you looked at it in terms of servicing, you defined it as:

  Trip = (Fill Tank,Leave San Diego,Fill Tank+,Arrive
  Albuquerque,(Oil Change?&Big Dinners*)

You specified some items, but you did not specify any details about what each item entails. For example, you perform the task Fill Tank several times during the course of the trip, but you never specify what filling the tank really involves. Through the process of specifying element hierarchy, you can define each element in the process.

Suppose that you define Fill Tank as follows:

  Fill Tank = (Find Gas Station,Pull Into Station,((Pull Up To
  Pump,Pay For Gas,Pump Gas,Get Change)&Stretch Legs&Use
  Restroom?),Leave Station)

This definition describes the task in more detail. It specifies all the steps and the order in which they are performed.

You have now defined the elements of your trip down two levels: the steps of the trip itself and the individual steps of one of the steps contained within the trip (Fill Tank).

In the same way, SGML documents can be composed of many elements, ranging from very large ones that consist of numerous subelements to others that might contain only a bit of text.

Earlier in this chapter, you saw some of the elements that this book contains. The list includes large elements, such as chapters, and small elements, such as chapter titles. When you think of all the elements that make up this book, you realize that you need a mechanism for defining the hierarchy.

Just as with your road trip, you can use the concept of hierarchy to define all the elements that make up this book. Through this hierarchy, the list of elements becomes more meaningful. This is because you can use the hierarchical approach to go recursively down through layer after layer, as deep as necessary, to define the data model thoroughly.

Take a look at figure 8.1. It shows a structural diagram of a book.

Fig. 8.1  This is a structural view of a book, illustrating the major components.

This diagram adds to your understanding of the book. Looking at it tells you much about how the elements within the book relate to one another and to the book overall.

You can now tell, for example, that a chapter includes a title, body, and one or more sections. One level below, sections contain a title and a body. This hierarchical structuring, or nesting, explains the relationships among the elements of this book. It is useful in content models, for it enables you to go as deep as you need to in defining structural relationships.

Take another look at the structure chart in figure 8.1. You could define this book by recursively defining each subsequent level in the structural tree. For example:

  Book=(TitlePg,TableContents,Foreword,Chapter+,
  (Bibliography&Appendix+),Index)
  TableContents=(TOCentry+)
  Foreword=(ForewordTitle,ForewordText)
  Chapter=(ChapTitle,ChapterBody,ChaptSect+)
  Bibliography=(ItemDesc,ItemPgNum)+
  Appendix=(ItemDesc,ItemPgNum)+
  Index=(IndexItem)+

This is very close to how a DTD representation of the book’s content model looks. A DTD for it appears at the end of this chapter.

Now that you have seen how to define structural hierarchies among nested elements, you can find out how to handle odd elements that might occur anywhere in the structure.

---

• See Chapter 10, “Following General SGML Declaration Syntax,” p. 171, for a discussion of SGML declaration syntax

---