| Previous | Table of Contents | Next |
Fragment Assembly
The previous example showed how to make components through fragment assembly. You define a DTD (or document) fragment and give it a PUBLIC name. You reference this public entity in your DTD and include the objects—elements, attributes, and so on—that are defined in the fragment.
Document fragments typically are not full-blown DTDs on their own. They normally consist of object definitions through elements, attributes, and entities. They can be referenced by other objects within the fragment DTD. Think of them as toolboxes, full of bits and pieces that come in handy from time to time.
You can take several approaches with the fragment assembly method. You can include all the reusable document objects in one fragment or many. If your document universe is complex, you can have a correspondingly complex collection of reusable document DTD fragments.
Table 11.2 describes some of the purposes for which fragment libraries are used.
| Fragment Type | Usage |
|---|---|
| Standard document structures | Define standard and generic objects commonly used in documents, such as subsections, tables, and lists. |
| Special procedures | Define special document sections that occur across multiple types of documents, such as assembly procedures and safety instructions. |
| Special characters or symbols | Define non-standard characters that are commonly used across documents, such as mathematical symbols and foreign language character sets. |
| Graphics or illustration structures | Define a standard set of graphics definitions, such as separate definitions for raster and vector graphics data references. |
Tip:
When you use fragment libraries, be sure to define the appropriate parameter entity in your DTD before you reference the document objects contained within it. If you don’t, you won’t be able to find the referenced object.
DTD Redefinition
DTD redefinition enables you to override an original object definition. Consider figure 11.5. This DTD contains the definition of a procedure.
)
Fig. 11.5 In this example, objects are defined through the use of entities.
The element advisory definition includes the entity reference %idinfo. Note that idinfo, as defined, contains the elements advnbr, type, and product.
Tip:
Remember: You must reference entities before you can use them.
Now suppose that you want to use these same objects in a new DTD, but with a twist. You want to include the same information, but you want to have an expanded definition for what is in the entity idinfo. You want to define idinfo so that it contains advnbr, type, product, and date. Because the SGML syntax ignores attempts to redefine an entity, you can create a new definition of idinfo before you call the old one by means of an entity reference to docpart. Figure 11.6 shows you how to do this.
)
Fig. 11.6 By ‘redefining’ an entity before its reference, you can override its original definition.
In this example, because the entity idinfo is defined so that it contains date, this definition holds even after you call the subsequent definition of idinfo contained in the entity docpart. In other words, because you defined the entity before the call in a different definition of the same entity, the first definition remains current.
Note:
If entities are redefined, the new definition is ignored.
Defining Parameter Entities as Elements
This approach to modularization is the most powerful—and most complex. With it, you can define a SYSTEM entity, which might contain a database query or check an online news feed, for example. The entity could contain the results of the query or check. It could also contain the result of specific processing on the values obtained from the query or check. You can use the entity to define an element dynamically, as shown in figure 11.7.
)
Fig. 11.7 By defining DTD elements through parameter entities, the results of complex external processing can be used.
The results of the datafeed entity could result in the dynamic construction of the document definition, or content model, itself. (Remember: The entity is composed of a processing command.) Through this mechanism, you can conceivably construct documents on the fly. You can choose key components of the document model depending on user queries and the like.
• See “Object-Oriented Technology and the Future of SGML Development,” p. 550
From Here…
In this chapter, you examined how to use modular DTD components. You saw that a modular approach can often simplify both your DTDs and the effort required to maintain, modify, and enhance them. You saw various ways to make your DTDs more modular.
When you find yourself in a dynamic SGML environment, the modular approach can speed the DTD development cycle and help ensure a common look across your various document types.
In the following chapters, you will examine ways to make your DTDs more intelligible. You will find out what makes a DTD good and how parsers can help you in the process.
For more information, refer to the following:
- • Chapter 12, “Formatting the DTD for Humans,” covers tips to make your DTD more understandable to humans.
- • Chapter 13, “Evaluating DTDs and Using Parsers,” discusses how to ensure your DTDs meet your needs, and how to use parsers in the process.
- • Chapter 14, “Following Good SGML Practice,” examines recommended approaches and practices in using SGML.
- • Chapter 13, “Evaluating DTDs and Using Parsers,” discusses how to ensure your DTDs meet your needs, and how to use parsers in the process.
| Previous | Table of Contents | Next |