Customization Layers

SGML and XML DTDs are really just collections of declarations. These declarations are stored in one or more files. A complete DTD is formed by combining these files together logically. Parameter entities are used for this purpose. Consider the following fragment:


<!ENTITY % dbpool SYSTEM "dbpool.mod"> (1)
<!ENTITY % dbhier SYSTEM "dbhier.mod"> (2)
%dbpool;                               (3)
%dbhier;                               (4)
(1)
This line declares the parameter entity dbpool and associates it with the file dbpool.mod.
(2)
This line declares the parameter entity dbhier and associates it with the file dbhier.mod.
(3)
This line references dbpool, which loads the file dbpool.mod and inserts its content here.
(4)
Similarly, this line loads dbhier.mod.

It is an important feature of DTD parsing that entity declarations can be repeated. If an entity is declared more than once, then the first declaration is used. Given this fragment:


<!ENTITY foo "Lenny">
<!ENTITY foo "Norm">

The replacement text for foo is "Lenny."

These two notions, that you can break a DTD into modules referenced with parameter entities and that the first entity declaration is the one that counts, are used to build "customization layers." With customization layers you can write a DTD that references some or all of DocBook, but adds your own modifications. Modifying the DTD this way means that you never have to edit the DocBook modules directly, which is a tremendous boon to maintaining your modules. When the next release of DocBook comes out, you usually only have to make changes to your customization layer and your modification will be back in sync with the new version.

Customization layers work particularly well in DocBook because the base DTD makes extensive use of parameter entities that can be redefined.