XSD-based document-type shells are organized into sections; each section contains a specific type of declaration.
XSD-based document-type shells use the XML Schema redefine feature
(<xs:redefine>
) to override base group definitions for content models
and attribute lists. This facility is analogous to the parameter entities that are used for
DTD-based document-type shells. Unlike DTD parameter entities, an
<xs:redefine>
both includes the XSD file that it redefines and holds
the redefinition that is applied to the groups in the included XSD file. Thus, for XSD files
that define groups, the file can be included using <xs:include>
if it
is used without modification or using <xs:redefine>
if any of its
groups are redefined.
XSD-based document-type shells contain the following sections.
For each element or attribute domain that is integrated into the document-type shell,
this section uses an <xs:include>
element to include the XSD
module for that domain.
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:deliveryTargetAttDomain.xsd:1.3"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:highlightDomain.xsd:1.3"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:indexingDomain.xsd:1.3"/>
The group inclusion section contains <xs:include>
or
<xs:redefine>
references for element groups. The group files
define named groups that are used to integrate domain-provided element and attribute
types into base content models. There is one group file for each structural type; domain
files can also have group files.
For both map and topic shells, this section also must include or redefine the following groups; it must also include the module file for each group:
The group files and the module files for base groups can be specified in any order.
For each element extended by one or more domains, the document-type shell must redefine
the model group for the element to a list of alternatives including the literal name of
the element and the element extension model group from each domain that is providing
specializations. To integrate a new domain in the document-type shell, use the schema
<xs:redefine>
mechanism to import a group definition file while
redefining and extending an element from that group. The model group requires a
reference to itself to extend the base model group.
For each attribute extended by one or more domains, the document-type shell must
redefine the attribute extension model group for the attribute to a list of alternatives
including the literal name of the attribute and the attribute extension model group from
each domain that is providing specializations. To integrate a new attribute domain in
the document-type shell, use the schema <xs:redefine>
mechanism
to import the commonElementGrp.xsd group file while redefining and
extending the base attribute.
<metadata>
element from the metadata group. It also extends the
@props
attribute from the common element module to add the specialized
attribute
@deliveryTarget
.<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:metaDeclMod.xsd:1.3"/>
<!-- ... -->
<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:commonElementGrp.xsd:1.3">
<!-- ...Redefinition of any elements in common module -->
<xs:attributeGroup name="props-attribute-extensions">
<xs:attributeGroup ref="props-attribute-extensions"/>
<xs:attributeGroup ref="deliveryTargetAtt-d-attribute"/>
</xs:attributeGroup>
</xs:redefine>
<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:metaDeclGrp.xsd:1.3">
<xs:group name="metadata">
<xs:choice>
<xs:group ref="metadata"/>
<xs:group ref="relmgmt-d-metadata"/>
</xs:choice>
</xs:group>
</xs:redefine>>
The module inclusion section includes the module XSD files for structural types used in the shell. These must be placed after the group and files and redefinitions.
This section must also include any other module XSD files required by the topic or map types. For example, if a troubleshooting specialization is specialized from topic but includes elements from task, then the task structural module must be included in the document shell.
If a structural type is constrained, that constraint will be included rather than the module itself; for example, in a document-type shell that constrains the task specialization, the task constraint module will be included rather than the task module.
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:topicMod.xsd:1.3"/>
<xs:include schemaLocation="urn:oasis:names:tc:dita:xsd:conceptMod.xsd:1.3"/>
The @domains
attribute declaration section declares the
@domains
attribute for the shell. It does this by redefining the
domains-att
group, adding one token for each vocabulary and
constraint module integrated by the shell. See domains attribute rules and syntax for details on the syntax
for domains tokens.
domains-att
to include the OASIS domains for map group, indexing, and
@deliveryTarget
:<xs:attributeGroup name="domains-att">
<xs:attribute name="domains" type="xs:string"
default="(map mapgroup-d) (topic indexing-d) a(props deliveryTarget)"/>
</xs:attributeGroup>
This section defines whether and how topics can nest by redefining the
info-types
group. That group is referenced but undefined in the
module files, so it must be defined in the shell. Topic testing can be disallowed by
setting the info-types
group to reference the
<no-topic-nesting>
element, with the @maxOccurs
and @minOccurs
attributes each set to "0".
Optionally, topictype-info-types
groups can be
redefined to provide more fine grained control of nesting with specialized topic types.
As with domain extensions, this is done by redefining the group while importing the
module that defines the group.
For example, in the concept vocabulary module delivered by OASIS,
the concept-info-types
group controls which topics can nest inside the
<concept>
element. That group is defined as including
<concept>
plus the info-types
group. The
following examples demonstrate how to control topic nesting within
<concept>
using a document-type shell.
<concept>
only nest itself, the
info-types
group must be defined so that it does not add any
additional
topics:<xs:group name="info-types">
<xs:choice>
<xs:element ref="no-topic-nesting" maxOccurs="0" minOccurs="0"/>
</xs:choice>
</xs:group>
<concept>
,
the concept-info-types
group must be redefined to remove
<concept>
, and the info-types
group must be
defined as
above:<xs:group name="info-types">
<xs:choice>
<xs:element ref="no-topic-nesting" maxOccurs="0" minOccurs="0"/>
</xs:choice>
</xs:group>
<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:conceptMod.xsd:1.3" >
<xs:group name="concept-info-types">
<xs:choice>
<xs:group ref="info-types"/>
</xs:choice>
</xs:group>
</xs:redefine>
<topic>
as a nesting topic within
<concept>
, define info-types
to allow any
number of <topic>
elements:<xs:group name="info-types">
<xs:choice>
<xs:element ref="topic" maxOccurs="unbounded" minOccurs="0"/>
</xs:choice>
</xs:group>
<concept>
is allowed to nest
either <concept>
or <topic>
. In order to
make <topic>
the only valid child topic, the
concept-info-types
must be redefined as
follows:<xs:redefine schemaLocation="urn:oasis:names:tc:dita:xsd:conceptMod.xsd:1.3" >
<xs:group name="concept-info-types">
<xs:choice>
<xs:group ref="info-types"/>
</xs:choice>
</xs:group>
</xs:redefine>