DTD: Coding requirements for constraint modules
A structural constraint module defines the constraints for a map or topic element type. A domain constraint module defines the constraints for an element or attribute domain.
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;">
Parent topic