Previous | Table of Contents | Next |
As you think of this book, you can picture a document model containing a foreword, a number of chapters, an index, and so on. In examining the structure of our content model, you can visualize an ordered relationship with each element having a place.
In some cases, however, elements float about freely and occur in a number of places. To understand this better, consider your road trip to Albuquerque.
You could define the journey in the following way:
Trip = (Leave San Diego,First 1/4 journey,Second 1/4 journey,Third 1/4 journey, Fourth 1/4 journey,Arrive Albuquerque)
You can modify this definition to include meals. However, there is a complication. When you travel, you dont always eat at predictable times. You might skip meals to cover more miles, or you might stop a few times, walk around and take in the sights, and work up a hearty appetite. In short, you just dont know how often and when you will stop to eat.
In this situation, you can use inclusion to specify meals along the way. Inclusion is a method of specifying elements or other data that can occur anywhere within another element. It is particularly useful for items that float throughout a structure.
In the case of the trip, you can modify the definition:
Trip = (Leave San Diego,First 1/4 journey,Second 1/4 journey,Third 1/4 journey, Fourth 1/4 journey, Arrive Albuquerque) +(Meals+)
The trip now consists of the following parts in this order:
The notation +(item) is a mechanism for indicating that item can occur within any of the elements in the model groupthat is, within any of the elements within the parentheses. In this case, the inclusion element is specified as Meals+, or one or more meals.
You might say, This is fine for meals on the road, but what does it have to do with document structures? After all, you dont want to have title pages or indexes floating about in a document. On the other hand, elements such as figure references, footnotes, and hypertext links in electronic documents can float throughout a document, popping up legitimately in many places.
Note:
Inclusion implies floating objects that can occur anywhere, while structure is generally a bit more rigid, implying order as well as content. Therefore, inclusion generally should not be used for structural elements or for elements that are tied to the ordered sequence of a document structure.
Exclusion works much like inclusion, except in reverse. For example, if you want to exclude getting speeding tickets from the trip, you can do this:
Trip = (Leave San Diego,First 1/4 journey,Second 1/4 journey,Third 1/4 journey, Fourth 1/4 journey, Arrive Albuquerque) -(Speeding Tickets)
Note:
Inclusions and exclusions can occur in the same element definition. If they cover the same element, exclusion wins (as defined in the SGML standard, ISO 8879).
Inclusion and exclusion are often used in conjunction with specific model groupsgroups of elements. In the definition of this book, for example, you can enable specific elements to float. That is, they are permitted to occur within other elements.
Suppose that you want to permit a paragraph to contain a number of elements. They might include tables and figures; references to tables, figures, chapters, and appendixes; and special typefaces, such as bold or italic. In a similar way, you might want to exclude specific elements from other structures. For example, you can exclude bulleted lists from footnotes.
Take a look at figure 8.2. It shows a revised structure diagram of a book. Inclusion has been added for references that can occur anywhere within the ChapterBody and SectionBody element definitions.
Fig. 8.2 Here is a revised look at a book structure, using inclusions for references to figures, lists, and tables.
Figure 8.3 is a DTD that models this structure. It shows how you can define the element relationships discussed in this chapter.
Fig. 8.3 This is an example of a document type definition (DTD) for a book.
If some of the DTD syntax is unfamiliar, dont worry. You will explore DTDs in much more detail in Part III, Content Modeling: Developing the DTD. See Chapter 10, Following General SGML Declaration Syntax, for a discussion of the syntax in DTDs. Chapter 11 discusses how to make DTD components. Chapter 13 examines the evaluation of DTDs and the use of parsers.
Note:
#PCDATA is the SGML terminology for character data that can be evaluated by an SGML parser. See Chapter 10, Following General SGML Declaration Syntax, for a description of #PCDATA.
In this chapter, youve seen how elements can relate to each other through the use of hierarchy, sequence, inclusion/exclusion, and occurrence. You also examined the notation for defining the relationships among elements. From here, you will examine the details involved in developing a DTD.
For more information, see the following chapters:
Previous | Table of Contents | Next |