XML Schema: Coding requirements for constraint modules
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
commonElementsMod.xsd, you must remove any <xs:include> reference to
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
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
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
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
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>