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.
<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;">