QR code for this page

Powered by Titania Delivery

XML Schema: 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.

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>
Parent topic: XML Schema coding requirements

Was this helpful?