Topic Constraint Module Step 3: Define the New Content Models

The base content model for the <p> element is defined in a parameter entity named %p.content; (by the general DITA 1.2 rules for constructing DTD-syntax element type declarations). Thus we need to declare our own version of %p.content; with the content model we want.

We want to allow only #PCDATA and the element types <b>, <i>, and <u>, or any specializations of those types.

Thus, the content model should be defined as:

(#PCDATA |
 %b; |
 %i; |
 %u;)*

To allow specializations of these element types we need to reference the tagname parameter entities for them, not the bare element type names. That is, we want to use "%b;" not just "b" in the content models. Because of the way parameter entity declaration precedence works in DTDs we have to declare the tagname parameter entities in the constraint module to ensure they are declared before they are used in the content model.

Given this knowledge, add the following parameter entity declarations to the constraint module file:

<?xml version="1.0" encoding="UTF-8"?>
<!-- ======================================
     Constraint Domain: Paragraphs with
     only highlight domain elements.
     
     Copyright (c) 2011 Your Name Here
     
     ====================================== -->

<!ENTITY topic-constraints "(topic highlightOnlyTopic-c)" >

<!ENTITY % b           "b"            >
<!ENTITY % i           "i"            >
<!ENTITY % u           "u"            > 

<!ENTITY % p.content 
  "
  (#PCDATA |
   %b; |
   %i; |
   %u;)*
  ">

     
<!-- ============ End of constraint module -->

That's the entire constraint module.

It may seem odd that we have to declare tagname entities that are already declared in the base module. However, there is an order of inclusion problem that can't be worked around any other way.

In DTDs, the first declaration of a parameter entity name wins. This is why the module files are included last in document type shells: they have to give domain modules and constraint modules the opportunity to override any parameter entities declared in the base module.

Likewise, constraint modules are included after any domain entity files and after the domain integration parameter entities in the document type shell so they will use any element-type-specific integrations in the constrained content models they define. But because the tagname parameter entities used in the constraint module may not be overridden by domains in a given shell, the constraint module has to declare the tagname parameter entities locally just to be sure.