XML Schema: Coding requirements for constraint modules

Darwin Information Typing Architecture (DITA) Version 1.3 Part 1: Base Edition

version
1.3
author
OASIS DITA Technical Committee

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.

All vocabulary and constraint modules must document their domains attribute contribution. The OASIS grammar files use a dita:domainsModule element to document the contribution; this element is used consistently to make it easy to find values when creating a document type shell. An XML comment or xs:appinfo element can also be used.

For each vocabulary module with a content model or attributes to be constrained, there must be an xs:redefine element that references the vocabulary module. Within the xs:redefine element, for each element type content model to be constrained, an xs:group element is needed with the name element.content. Also within the xs:redefine element, for each attribute set to be constrained, an xs:attributeGroup element is needed with the name element.attributes. The constrained model is defined inside of the xs:group or xs:attributeGroup.

Note: This means that when adding a constraint module to an existing document-type shell, you must remove any xs:include elements that refer to the XSD module to which the redefine is applied. For example, to redefine groups defined in commonElementsMod.xsd, you must remove any xs:include reference to commonElementsMod.xsd.

Because the constraint module includes the module that it modifies, only one constraint module can be used per vocabulary module (otherwise the module being constrained would be included multiple times). If multiple constraint modules are needed for a single vocabulary module, they must be combined into a single XSD module. For example, when combining existing constraint modules for p and div, a single module must be created that combines the xs:group and xs:attributeGroup constraints from existing modules inside a single xs:redefine reference to commonElementsMod.xsd.

When constraining a list of elements provided by a domain, there must be a group that lists the subset of domain elements in a constraints module. The group name SHOULD be named "qualifierdomain-c-tagname" where qualifier is a description for the constraint module, domain is the name of the domain, map, or topic being constrained, and tagname is the name of the extension element being restricted.

Example: Structural constraint module

The following code fragment shows how the topic element can be constrained to disallow the body element. This xs:redefine element is located in a constraint module that references the file topicMod.xsd, which means that a document-type shell using this constraint would reference this module instead of referencing topicMod.xsd (it would not reference both).

<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:topicMod.xsd:1.2">
  <xs:group name="topic.content">
    <xs:sequence>
      <xs:sequence>
        <xs:group ref="title"/>
        <xs:group ref="titlealts" minOccurs="0"/>
        <xs:choice minOccurs="1" >
          <xs:group ref="shortdesc" />
          <xs:group ref="abstract" />
        </xs:choice>
        <xs:group ref="prolog" minOccurs="0"/>
        <!--<xs:group ref="body" minOccurs="0"/>-->
        <xs:group ref="related-links" minOccurs="0"/>
        <xs:group ref="topic-info-types" minOccurs="0"
          maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:sequence>
  </xs:group>
</xs:redefine>

For a more complete example, see strictTaskbodyConstraintMod.xsd, delivered with the DITA 1.3 grammar files.

Example: Domain constraint module

The following code fragment shows how the highlighting domain can be constrained to limit the elements that are available in the domain to only b and i.

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