###### 2.1.4.4.4 Examples of constraint declaration modules

This section provides examples of constraint declaration modules.

###### Constraining element content in a topic vocabulary module

A constraint module named shortdescReq redefines the content model of the <topic> element so that the <shortdesc> element is required. The DTD declarations for this module would be:

    <!ENTITY shortdescReq.constraint
      "(topic shortdescReq-c)"
    >

    <!ENTITY % topic.content
       "((%title;),
         (%titlealts;)?,
         (%shortdesc;),
         (%prolog;)?,
         (%body;)?,
         (%related-links;)?,
         (%topic-info-types;)*)"
    >
    <!ENTITY % topic.attributes
                "id          ID                                #REQUIRED
                 conref      CDATA                             #IMPLIED
                 %select-atts;
                 %localization-atts;
                 outputclass CDATA                             #IMPLIED">
    ...
    <!ELEMENT topic  %topic.content;>
    <!ATTLIST topic  %topic.attributes;>
    <!ATTLIST topic
                 %arch-atts;
                 domains    CDATA
                 "&included-domains;"
    >

[Anderson 17 May 2010] The following section about domain vocabulary modules was removed until a sample can be completed.

###### Integrating a subset of the extension elements from a domain module

A constraint module named basicHighlight includes the <b> and <i> elements but not the <u>, <sub>, <sup>, and <tt> elements from the highlight domain. The DTD declarations for this module would be:

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

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

The XSD declarations for this module would be:

    <xs:group name="basicHighlight-c-ph">
      <xs:choice>
        <xs:element ref="b"/>
        <xs:element ref="i"/>
      </xs:choice>
    </xs:group>

[Anderson, 17 May 2010: Previous content was as follows. I've replaced it below while commenting out the noNestedHighlight sample above. Ideally this can be reintroduced when the noNestedHighlight sample is completed.

Note that because the noNestedHighlight constraint module shown above redefines content models and the basicHighlight constraint module subsets extension, these constraints don't conflict in attempting to revise the same content model and thus can be combined in the same shell document type. The effective value of the @domains attribute will include the contributions from both constraint modules, as well as any other modules integrated by the shell, e.g.:

    ...
    (topic hi-d noNestedHighlight-c)
    (topic hi-d basicHighlight-c)
    ...

Note that the basicHighlight constraint module subsets extension, but does not redefine any content models. If another constraint is created to restrict the content model of the <b> element, it will not conflict with the basicHighlight domain, because they do not attempt to revise the same content model. This means that the two can be combined in the same shell document type. The effective value of the @domains attribute will include the contributions from both constraint modules, as well as any other modules integrated by the shell, e.g.:

    ...
    (topic hi-d noNestedHighlight-c)
    (topic hi-d basicHighlight-c)
    ...

###### Applying multiple constraints to a single vocabulary module

A constraint module named simpleSection redefines the content models of the <section> and <example> elements to allow a single initial <title> element and to remove text and phrase elements. Because this constraint module redefines different elements than the shortdescReq constraint module shown above, both modules can apply to the topic module. The order in which the constraint modules are listed is not significant. The DTD declarations for this module would be:

    <!ENTITY simpleSection.constraints
      "(topic simpleSection-c)"
    >

    <!ENTITY % section.content
      "((%title),
        (%basic.block; |
         %data.elements.incl; |
         %foreign.unknown.incl; |
         %sectiondiv;)*)

      "
    >

Note that this constraint module and the shortdescReq constraint module both constrain task but because they constrain different element types they do not conflict and can be used together. Each constraint module provides its own contribution to the @domains attribute, so that when integrated the effective value of the @domains attribute will include the declarations for both constraint modules, as well as the declarations for the other modules integrated by the shell document type, e.g.:

    ...
    (topic shortdescReq-c)
    (topic simpleSection-c)
    ..

###### A topic with elements replaced by domain extensions

A document type shell replaces the <ph> element with extension elements from the highlighting and programming domains. Because the highlighting and programming domains cannot be generalized to a topic without the <ph> element, the removal constraint must be declared on the topic module with a separate parenthetical expression.

The @domains attribute declaration:

    (topic noBasePhrase-c)
    (topic hi-d)
    (topic pr-d)

Previous Topic: 2.1.4.4.3 Conref and generalization for constraint modules

Next Topic: Technical content architecture

Parent Topic: 2.1.4.4 Constraints

Sibling Topics:

2.1.4.4.1 Constraint module DTD coding requirements

2.1.4.4.2 Constraint module XSD coding requirements

2.1.4.4.3 Conref and generalization for constraint modules