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.
<!ENTITY % pre "%pr-d-pre; | %sw-d-pre; | %ui-d-pre;">