###### 2.1.4.4.1 Constraint module DTD coding requirements

###### Requirements for structural constraint modules

A structural constraint module defines the constraints for exactly one map or topic element type.

Constraint modules should be named "qualifier tagnameConstraints.mod", where qualifier is specific to the constraints module and characterizes it, e.g. "strict", "requiredTitle", etc. and tagname is the name of the element type to which the constraints apply, e.g. "topic", "p", "myNewTopicType", etc.

Within the constraint module there must be a declaration for a general text entity named "tagname-constraints", where tagname is the name of the element type to which the constraints apply. The replacement text for the entity must be of the form "(tagname qualifier Tagname-c)", where tagname is the name of the element type to which the constraints apply, qualifier is as for the module filename (e.g., "strict"), and Tagname is the element type name with an initial capital (e.g. "Topic"). The literal "-c" indicates that the name is the name of a constraints domain. There must also be a declaration of the %tagname.content parameter entity that defines the constrained content model. For example:

    <!ENTITY  topic-constraints  "(topic strictTopic-c)">
    <!ENTITY % topic.content
      "((%title;),
        (%titlealts;)?,
        (%shortdesc;|
         %abstract;),
        (%prolog;)?,
        (%body;)?,
        (%topic-info-types;)*)"
    >

In this example, the shortdesc-or-abstract choice, which is optional in the base <topic> content model, is required, defining a more-constrained content model.

###### Requirements for domain constraint modules

A domain constraint module defines the constraints for exactly one element domain module.

Domain constraint modules should be named "qualifier domainDomainConstraints.mod", where qualifier is specific to the constraints module and characterizes it, e.g. "strict", "requiredTitle", etc. and domain is the name of the domain to which the constraints apply, e.g. "hi-d", "pr-d", "mydomain-d", etc.

Within the constraint module there must be a declaration for a general text entity named "tagname-constraints", where tagname is the name of the element type to which the constraints apply. The replacement text for the entity must be of the form "(tagname qualifier Tagname-c)", where tagname is the name of the element type to which the constraints apply, qualifier is as for the module filename (e.g., "strict"), and Tagname is the element type name with an initial capital (e.g. "Topic"). The literal "-c" indicates that the name is the name of a constraints domain. There must also be a declaration of the %tagname.content parameter entity that defines the constrained content model.

For example:

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

    <!ENTITY   basicHighlight-c-att   "(topic hi-d basicHighlight-c)">

In this example, the set of highlight domain elements has been reduced to just <b> and <i>.

###### Requirements for shell document types

Information on how to incorporate a constraint module into a DTD document type shell can be found in 2.1.4.2.1 DTD document-type shell: Coding requirements.

Previous Topic: 2.1.4.4 Constraints

Next Topic: 2.1.4.4.2 Constraint module XSD coding requirements

Parent Topic: 2.1.4.4 Constraints

Sibling Topics:

2.1.4.4.2 Constraint module XSD coding requirements

2.1.4.4.3 Conref and generalization for constraint modules

2.1.4.4.4 Examples of constraint declaration modules