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