DTD: Coding requirements for constraint modules

Structural constraint modules

Structural constraint modules have the following requirements:

@domains contribution entity name and value

The constraint module should contain a declaration for a text entity with the name tagname-constraints, where tagname is the name of the element type to which the constraints apply. The value of the text entity is the @domains attribute contribution for the module; see domains attribute rules and syntax for details on how to construct this value.

For example, the following text entity provides the declaration for the strict task constraint that is shipped with the DITA standard.

<!ENTITY taskbody-constraints     
  "(topic task strictTaskbody-c)"
>

The tagname.attributes parameter entity

When the attribute set for an element is constrained, there must be a declaration of the tagname.attributes parameter entity that defines the constrained attributes.

For example, the following parameter entity defines a constrained set of attributes for the <note> element that removes most of the values defined for @type, and also removes @spectitle and @othertype:

<!ENTITY % note.attributes  
       "type  (attention | caution | note ) #IMPLIED
        %univ-atts;
        outputclass  CDATA  #IMPLIED">

The tagname.content parameter entity

When the content model for an element is constrained, there must be a declaration of the tagname.content parameter entity that defines the constrained content model.

For example, the following parameter entity defines a more restricted content model for <topic>, in which the <shortdesc> element is required.

<!ENTITY % topic.content 

  "((%title;), 
    (%titlealts;)?, 
    (%shortdesc;), 
    (%prolog;)?, 
    (%body;)?, 
    (%topic-info-types;)*)"
>

Domain constraint modules

Domain constraint modules have the following requirements:

@domains contribution entity name and value

The constraint module should contain a declaration for a text entity with the name domainDomain-constraints, where domain is the name of the domain to which the constraints apply, for example, "Highlighting" or "Programming". The value of the text entity is the @domains attribute contribution for the module; see domains attribute rules and syntax for details on how to construct this value.

For example, the following text entity provides the declaration for a constraint module that restricts the highlighting domain:

<!ENTITY HighlightingDomain-constraints     
  "(topic hi-d basic-HighlightingDomain-c)"
>

Parameter entity

When the set of extension elements are restricted, there must be a parameter entity that defines the constrained content model.

For example, the following parameter entity restricts the highlighting domain to <b> and <i>:


<!ENTITY % HighlightingDomain-c-ph     "b | i"  >

Constraining to replace a base element with domain extensions

When element domains are used to extend a base element, those extensions can be used to replace the base element. This form of constraint is done inside the document-type shell.

Within a document-type shell, domain extensions are implemented by declaring an entity for a base element. The value of the entity can omit any base element types from which the other element types that are listed are specialized. Omitting a base type constitutes a form of constraint; as with any other constraint, this form of constraint must contribute a token to the @domains attribute. That token can be defined in a module file (which does not define any other entities or values), or the token can be placed directly into the document-type shell definition for the included-domains entity.

In the following example, the <pre> base type is removed from the entity declaration, effectively allowing only specializations of <pre> but not <pre> itself. This omission would require the use of a @domains contribution token within the included-domains entity.

<!ENTITY % pre
    "%pr-d-pre; | 
     %sw-d-pre; | 
     %ui-d-pre;">