Just as there may be more elements than you need, there may be more attributes.
Suppose you want to remove the RenderAs attribute from the Sect1 element. RenderAs allows the author to "cheat" in the presentation of hierarchy by specifying that the stylesheet should render a Sect1 as something else: a Sect3, perhaps. Example 5-11 details the removal of RenderAs.
Example 5-11. Removing RenderAs from Sect1
DocBook defines eleven common attributes; these attributes appear on every element. Depending on how you're processing your documents, removing some of them can both simplify the authoring task and improve processing speed.
Some obvious candidates are:
If you're not using all of the effectivity attributes in your documents, you can get rid of up to seven attributes in one fell swoop.
If you're not producing multilingual documents, you can remove Lang.
The Remap attribute is designed to hold the name of a semantically equivalent construct from a previous markup scheme (for example, a Microsoft Word style template name, if you're converting from Word). If you're authoring from scratch, or not preserving previous constructs with Remap, you can get rid of it.
If your processing system isn't using XrefLabel, it's a candidate as well.
The customization layer in Example 5-12 reduces the common attributes to just ID and Lang.
Example 5-12. Removing Common Attributes
<!ENTITY % common.attrib "ID ID #IMPLIED Lang CDATA #IMPLIED" > <!ENTITY % idreq.common.attrib "ID ID #REQUIRED Lang CDATA #IMPLIED" > <!-- load DocBook --> <!ENTITY % DocBookDTD PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> %DocBookDTD; |
By definition, whatever attributes you define in the common.attrib and idreq.common.attrib parameter entities are the common attributes. In dbpool.mod , these parameter entities are defined in terms of other parameter entities, but there's no way to preserve that structure in your customization layer.