Expansion modules

This section is non-normative.

This section of the specification contains examples of expansion modules implemented using both DTD and RNG.

This section is non-normative.

This section of the specification contains examples of extension modules that are implemented using DTDs.

Example: Adding an element to the <section> element using DTDs

This section is non-normative.

In this scenario, a DITA architect wants to modify the content model for the <section> element. The DITA architect wants to add an optional <sectionDesc> element that is specialized from <p>.

Example

This section is non-normative.

To accomplish this, the DITA architect needs to create the following modules and integrate them into the document-type shell:

  • An element-domain specialization module that defines the <sectionDesc> element
  • An expansion module that adds the <sectionDesc> element to the content model for <section>
  1. First, the DITA architect creates the element specialization module: sectionDescDomain.mod. This single .mod file defines the parameter entity, content model, attributes, and value for the @class attribute for <sectionDesc>.
    <?xml version="1.0" encoding="UTF-8"?>

<!ENTITY % sectionDesc "sectionDesc">

<!ENTITY % sectionDesc.content "(%para.cnt;)*">
<!ENTITY % sectionDesc.attributes "%univ-atts;">

<!ELEMENT sectionDesc %sectionDesc.content;>
<!ATTLIST sectionDesc %sectionDesc.attributes;>

<!ATTLIST sectionDesc    class CDATA "+ topic/p sectionDesc-d/sectionDesc ">
  2. The DITA architect adds the element specialization module to the catalog.xml file.
  3. Next, the DITA architect modifies the applicable document-type shell to integrate the applicable element specialization module:
    <!-- ============================================================= -->
<!--                    DOMAIN ELEMENT INTEGRATION                 -->
<!-- ============================================================= -->

<!-- ... other domains ... -->

<!ENTITY % sectionDesc-d-def
  PUBLIC "-//ACME//ELEMENTS DITA 2.0 Section Description Domain//EN"
         "sectionDescDomain.mod"
>%sectionDesc-d-def;

    At this point, the new domain is integrated into the topic document-type shell. However, the new element is not added to the content model for <section>.

  4. Next, the DITA architect creates an expansion module: acme-SectionExpansion.mod. This module adds the <sectionDesc> element to the content model of <section>.
    <?xml version="1.0" encoding="UTF-8"?>

<!-- Declares the entities referenced in the modified content  -->
<!-- model.                                                    -->

<!ENTITY % dl "dl">
<!ENTITY % div "div">
<!ENTITY % fig "fig">
<!ENTITY % image "image">
<!ENTITY % lines "lines">
<!ENTITY % lq "lq">
<!ENTITY % note "note">
<!ENTITY % object "object">
<!ENTITY % ol "ol">
<!ENTITY % p "p">
<!ENTITY % pre "pre">
<!ENTITY % simpletable "simpletable">
<!ENTITY % sl "sl">
<!ENTITY % table "table">
<!ENTITY % ul "ul">
<!ENTITY % cite "cite">
<!ENTITY % include "include">
<!ENTITY % keyword "keyword">
<!ENTITY % ph "ph">
<!ENTITY % q "q">
<!ENTITY % term "term">
<!ENTITY % text "text">
<!ENTITY % tm "tm">
<!ENTITY % xref "xref">
<!ENTITY % data "data">
<!ENTITY % foreign "foreign">
<!ENTITY % title "title">
<!ENTITY % draft-comment "draft-comment">
<!ENTITY % fn "fn">
<!ENTITY % indexterm "indexterm">
<!ENTITY % required-cleanup "required-cleanup">
<!ENTITY % sectionDesc "sectionDesc">

<!-- Defines the modified content model for <section>.       -->

<!ENTITY % section.content
              "(#PCDATA |
               %dl; |
               %div; |
               %fig; |
               %image; |
               %lines; |
               %lq; |
               %note; |
               %object; |
               %ol; |
               %p; |
               %pre; |
               %simpletable; |
               %sl; |
               %table; |
               %ul; |
               %cite; |
               %include; |
               %keyword; |
               %ph; |
               %q; |
               %term; |
               %text; |
               %tm; |
               %xref; |
               %data; |
               %foreign; |
               %title; |
               %draft-comment; |
               %fn; |
               %indexterm; |
               %required-cleanup; |
               %sectionDesc;)*"
>

    Note that the DITA architect needed to explicitly declare all the elements, rather than using the %section.cnt; parameter entity that is used in the definition of <section>. Because the element-configuration modules are integrated into the document-type shell before the base grammar modules, none of the parameter entities that are used in the base DITA vocabulary modules are available.

  5. Finally, the DITA architect integrates the expansion module into the document-type shell:
    <!-- ============================================================= -->
<!--           ELEMENT-TYPE CONFIGURATION INTEGRATION              -->
<!-- ============================================================= -->

<!-- Other constraint and expansion modules -->

<!ENTITY % acmeSection-def
  PUBLIC "-//ACME//ELEMENTS DITA 2.0 Section Expansion//EN"
         "acme-SectionExpansion.mod"
>%acmeSection-def;
  6. After updating the catalog.xml file to include the expansion module and testing it, the work is done.

Example: Adding an attribute to certain table elements using DTDs

This section is non-normative.

In this scenario, a company makes extensive use of complex tables to present product listings. They occasionally highlight individual cells, rows, or columns for various purposes. The DITA architect wants to implement a semantically meaningful way to identify the purpose of various table elements.

The DITA architect decides to create a new attribute (@cell-purpose) and add it to the attribute lists of the following elements:

  • <colspec>
  • <entry>
  • <row>
  • <stentry>
  • <strow>

The new attribute will be specialized from @base, and it will take a small set of tokens as values.

The DITA architect decides to integrate the attribute declaration and its assignment to elements into a single expansion module. An alternate approach would be to put each attribute-list pattern in its own separate expansion module, thus allowing DITA architects who construct document-type shells to decide the elements to which to apply the attribute.

  1. First, the DITA architect creates the expansion module for the @cell-purpose attribute: acme-cellPurposeAttExpansion.ent.
    <!-- Define the attribute -->
<!ENTITY % cellPurposeAtt-d-attribute-expansion
  "cell-purpose  (sale | out-of-stock | new | last-chance | inherit | none)  #IMPLIED"
>

<!-- Declare the entity to be used in the @specializations attribute -->
<!ENTITY cellPurposeAtt-d-att "@base/cell-purpose" >

<!-- Add the attribute to the elements. -->
<!ATTLIST entry %cellPurposeAtt-d-attribute-expansion;>
<!ATTLIST row %cellPurposeAtt-d-attribute-expansion;>
<!ATTLIST colspec %cellPurposeAtt-d-attribute-expansion;>
<!ATTLIST strow %cellPurposeAtt-d-attribute-expansion;>
<!ATTLIST stentry %cellPurposeAtt-d-attribute-expansion;>
    Note (non-normative):
    The attribute definition entity is optional. It is used here to enable the DITA architect to add the same attribute with the same tokens to several elements.
  2. They then update the catalog.xml file to include the expansion module.
  3. They integrate this module into the applicable document-type shell.
    <!-- ============================================================= -->
<!--             DOMAIN ATTRIBUTES DECLARATIONS                    -->
<!-- ============================================================= -->

<!-- ... other domains ... -->

<!ENTITY % cellPurposeAttExpansion-d-dec
  PUBLIC "-//ACME//ENTITIES DITA Cell Purpose Attribute Expansion//EN"
         "cellPurposeAttExpansion.ent"
>%cellPurposeAttExpansion-d-dec;
  4. They add the entity for the contribution to the @specializations attribute.
    <!-- ============================================================= -->
<!--                 SPECIALIZATIONS ATTRIBUTE OVERRIDE            -->
<!-- ============================================================= -->

<!ENTITY included-domains
                          "&audienceAtt-d-att;
                           &cellPurposeAtt-d-att;
                           &deliveryTargetAtt-d-att;
                           &otherpropsAtt-d-att;
                           &platformAtt-d-att;
                           &productAtt-d-att;"
>
  5. After checking the test topic to ensure that the attribute lists are modified as expected, the work is done.

Example: Adding an existing domain attribute to certain elements using DTDs

This section is non-normative.

In this scenario, a company wants to use the @otherprops attribute specialization. However, they want to make the attribute available only on certain elements: <p>, <div>, and <section>.

The DITA architect will need to create an extension module and integrate it into the appropriate document-type shells.

  1. The DITA architect creates an expansion module that adds the @otherprops attribute to the selected elements: acme-otherpropsAttExpansion.mod. The expansion module contains the following code:

    <?xml version="1.0" encoding="UTF-8"?>

<!-- Add the otherprops attribute to certain elements -->
<!ATTLIST p %otherpropsAtt-d-attribute;>
<!ATTLIST div %otherpropsAtt-d-attribute;>
<!ATTLIST section %otherpropsAtt-d-attribute;>

    Note that the %otherpropsAtt-d-attribute; is defined in the separate attribute-specialization module that defines the @otherprops attribute.

  2. They then update the catalog.xml file to include the expansion module.
  3. They integrate the extension module into the applicable document-type shell, after the declaration for the @otherprops attribute-specialization module:
    <!-- ============================================================= -->
<!--             DOMAIN ATTRIBUTES DECLARATIONS                    -->
<!-- ============================================================= -->
...

<!ENTITY % otherpropsAtt-d-dec
  PUBLIC "-//OASIS//ENTITIES DITA 2.0 Otherprops Attribute Domain//EN"
         "otherpropsAttDomain.ent"
>%otherpropsAtt-d-dec;

<!ENTITY % otherprops-expansion-e-def  
  PUBLIC "-//ACME//DITA 2.0 Otherprops Expansion//EN" 
         "acme-otherpropsAttExpansion.mod"
  >%otherprops-expansion-e-def;

...

  4. They remove the reference to the @otherprops attribute from the props-attribute-extension entity:

    <!-- ============================================================= -->
<!--                    DOMAIN ATTRIBUTE EXTENSIONS                -->
<!-- ============================================================= -->

<!ENTITY % base-attribute-extensions
  ""
>

<!ENTITY % props-attribute-extensions
  "%audienceAtt-d-attribute;
   %deliveryTargetAtt-d-attribute;
   %otherpropsAtt-d-attribute;
   %platformAtt-d-attribute;
   %productAtt-d-attribute;"
>
  5. They ensure that the included-domains entity contains the @otherprops contribution to the @specializations attribute: 
    <!-- ============================================================= -->
<!--                 SPECIALIZATIONS ATTRIBUTE OVERRIDE            -->
<!-- ============================================================= -->

<!ENTITY included-domains
                          "&audienceAtt-d-att;
                           &deliveryTargetAtt-d-att;
                           &otherpropsAtt-d-att;
                           &platformAtt-d-att;
                           &productAtt-d-att;"
>
  6. After checking the test topic to ensure that the attribute lists are modified as expected, the work is done.

Example: Aggregating constraint and expansion modules using DTDs

This section is non-normative.

The DITA architect wants to add some extension modules to the document-type shell for topic. The document-type shell already integrates a number of constraint modules.

The following table lists the constraints that are currently integrated into the document-type shell:

File name What it constrains Details
example-TopicConstraint.mod <topic>
  • Removes <abstract>
  • Makes <shortdesc> required
  • Removes <related-links>
  • Disallows topic nesting
example-SectionConstraint.mod <section>
  • Makes <title> required
  • Reduces the content model of <section> to a smaller subset
example-HighlightingDomainConstraint.mod Highlighting domain Reduces the highlighting domain elements to <b> and <i>

The following table lists the expansion modules that the DITA architect wants to add to the document-type shell:

File name What it modifies Details
acme-SectionExpansion.mod <section> Adds an optional <sectionDesc> element to <section>.
example-dlentryModeAttExpansion.ent <dlentry> Adds @dlentryMode to the attributes of <dlentry>.

The constraint and expansion modules that target the <section> element must be combined into a single element-configuration module. An element can only be targeted by a single element-configuration module.

This section is non-normative.

This section of the specification contains examples of extension modules implemented using RNG.

Example: Adding an element to the <section> element using RNG

This section is non-normative.

In this scenario, a DITA architect wants to modify the content model for the <section> element. He wants to add an optional <sectionDesc> element that is specialized from <p>; the <sectionDesc> can occur once and must be directly after the section title.

Example

This section is non-normative.

To accomplish this, the DITA architect needs to create the following modules and integrate them into the document-type shells:

  • An element domain module that defines the <sectionDesc> element
  • An expansion module that adds the <sectionDesc> element to the content model for <section>
  1. First, the DITA architect creates the element domain module: sectionDescDomain.rng. It contains the following code:
    <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:pubid:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
                         schematypens="http://relaxng.org/ns/structure/1.0"?>
<grammar xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
  xmlns:dita="http://dita.oasis-open.org/architecture/2005/" 
  xmlns="http://relaxng.org/ns/structure/1.0">
  <div>
    <a:documentation>DOMAIN EXTENSION PATTERNS</a:documentation>
  </div>
  <div>
    <a:documentation>ELEMENT TYPE NAME PATTERNS</a:documentation>
    <define name="sectionDesc">
      <ref name="sectionDesc.element"/>
    </define>   
  </div>
  <div>
    <a:documentation>ELEMENT TYPE DECLARATIONS</a:documentation>
    <div>
      <a:documentation>LONG NAME: Section Description</a:documentation>
      <define name="sectionDesc.content">
        <zeroOrMore>
            <ref name="para.cnt"/>
          </zeroOrMore>
      </define>
      <define name="sectionDesc.attributes">
        <ref name="univ-atts"/>
      </define>
      <define name="sectionDesc.element">
        <element name="sectionDesc" dita:longName="Section Description">
          <a:documentation/>
          <ref name="sectionDesc.attlist"/>
          <ref name="sectionDesc.content"/>
        </element>
      </define>
      <define name="sectionDesc.attlist" combine="interleave">
        <ref name="sectionDesc.attributes"/>
      </define>
    </div>
  </div>
  <div>
    <a:documentation>SPECIALIZATION ATTRIBUTE DECLARATIONS</a:documentation>
    <define name="sectionDesc.attlist" combine="interleave">
      <optional>
        <attribute name="class" a:defaultValue="+ topic/p sectionDesc-d-p/sectionDesc "/>
      </optional>
    </define>
  </div>
</grammar>
  2. The DITA architect adds the element domain module to the catalog.xml file.

  3. Next, the DITA architect modifies the document-type shell (in this example, the one for topic) to integrate the element domain module:

      <div>
    <a:documentation>MODULE INCLUSIONS</a:documentation>
    ...
    <include href="urn:pubid:example:names:tc:dita:rng:sectionDescDomain.rng:2.0"/>
  </div>

    At this point, the new domain is integrated into the document-type shell. However, the new element is not added to the content model for <section>.

  4. Next, the DITA architect created an expansion module (sectionExpansionMod.rng) that adds the <sectionDesc> element to the content model of <section>:

    <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:pubid:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
                         schematypens="http://relaxng.org/ns/structure/1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:dita="http://dita.oasis-open.org/architecture/2005/"
  xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <div>
    <a:documentation>CONTENT MODEL AND ATTRIBUTE LIST OVERRIDES</a:documentation>
    <include href="urn:pubid:oasis:names:tc:dita:rng:topicMod.rng:2.0">  
      <define name="topic-info-types">
        <ref name="topic.element"/>
      </define>    
      <define name="section.content">
        <optional>
          <ref name="title"/>
        </optional>
        <optional>
          <ref name="sectionDesc"/>
        </optional>
        <zeroOrMore>
          <ref name="section.cnt"/>
        </zeroOrMore>
      </define>
    </include>
  </div>
</grammar>

    Note that the expansion module directly integrates topicMod.rng.

  5. Finally, the DITA architect integrates the expansion module into the document-type shell and removes the inclusion statement for topicMod.rng:

      <div>
    <a:documentation>ELEMENT-TYPE CONFIGURATION INTEGRATION</a:documentation>
    <include href="sectionExpansionMod.rng"/>
  </div>
  <div>
    <a:documentation>MODULE INCLUSIONS</a:documentation>
    <include href="urn:pubid:oasis:names:tc:dita:rng:topicMod.rng:2.0">
      <define name="topic-info-types">
        <ref name="topic.element"/>
      </define>
    </include>
    ... 
    <include href="urn:pubid:example:names:tc:dita:rng:sectionDescDomain.rng:2.0"/>
  </div>
  6. After updating the catalog.xml file to include the expansion module and testing, the work is done.

Example: Adding an attribute to certain table elements using RNG

This section is non-normative.

In this scenario, a company makes extensive use of complex tables to present product listings. They occasionally highlight individual cells, rows, or columns for various purposes. The DITA architect wants to implement a semantically meaningful way to identify the purpose of various table elements.

The DITA architect decides to create a new attribute (@cell-purpose) and add it to the content model of the following elements:

  • <entry>
  • <row>
  • <colspec>
  • <stentry>
  • <strow>

The new attribute will be specialized from @base, and it will take a small set of tokens as values.

The DITA architect decides to integrate the attribute declaration and its assignment to elements into a single expansion module. An alternate approach would be to put each <!ATTLIST declaration in its own separate expansion module, thus allowing DITA architects who construct document-type shells to decide the elements to which to apply the attribute.

  1. The DITA architect creates an expansion module: cellPurposeAtt.rng. It contains the following code:

    <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:pubid:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
                         schematypens="http://relaxng.org/ns/structure/1.0"?>
<grammar 
  xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
  xmlns:dita="http://dita.oasis-open.org/architecture/2005/"
  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  
  <!-- DEFINE THE ATTRIBUTE SPECIALIZATION -->
  <define name="cellPurposeAtt">
    <optional>
      <attribute name="cellPurpose">
        <a:documentation>Specifies the purpose of the table cell. This is a specialized
          attribute for Acme Corporation.
        </a:documentation>
        <choice>
          <value>sale</value>
          <value>out-of-stock</value>
          <value>new</value>
          <value>last-chance</value>
          <value>inherit</value>
          <value>none</value>
        </choice>
      </attribute>
    </optional>
  </define>
  
  <!-- ASSIGN THE ATTRIBUTE TO CERTAIN ELEMENTS -->
  <define name="entry.attributes" combine="interleave">
    <ref name="cellPurposeAtt"/>
  </define>
  <define name="stentry.attributes" combine="interleave">
    <ref name="cellPurposeAtt"/>
  </define>
  <define name="row.attributes" combine="interleave">
    <ref name="cellPurposeAtt"/>
  </define>
  <define name="strow.attributes" combine="interleave">
    <ref name="cellPurposeAtt"/>
  </define>
  <define name="colspec.attributes" combine="interleave">
    <ref name="cellPurposeAtt"/>
  </define>
</grammar>

  2. They then update the catalog.xml file to include the expansion module.

  3. They integrate the expansion module into the document-type shell:

    <div>
    <a:documentation>MODULE INCLUSIONS</a:documentation>
    ...  
    <include href="urn:pubid:example:names:tc:dita:rng:cellPurposeAtt.rng:2.0"/>
  </div>
  4. They specify the value that the @cellPurpose attribute contributes to the @specializations attribute:
      <div>
    <a:documentation>SPECIALIZATIONS ATTRIBUTE</a:documentation>
    <define name="specializations-att">
      <optional>
        <attribute name="specializations" a:defaultValue="
                         @props/audience
                         @props/deliveryTarget
                         @props/otherprops
                         @props/platform
                         @props/product
                         @base/cellPurpose"/>
      </optional>
    </define>
  </div>
  5. After checking the test file to ensure that the attribute lists are modified as expected, the work is done.

Example: Adding an existing domain attribute to certain elements using RNG

This section is non-normative.

In this scenario, a company wants to use the @otherprops attribute specialization. However, they want to make the attribute available only on certain elements: <p>, <div>, and <section>.

The DITA architect will need to create an extension module and integrate it into the appropriate document-type shells.

  1. The DITA architect creates an expansion module that adds the @otherprops attribute to the selected elements: acme-otherpropsAttExpansion.rng. The expansion module contains the following content:

    <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:pubid:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
                         schematypens="http://relaxng.org/ns/structure/1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
  xmlns:dita="http://dita.oasis-open.org/architecture/2005/"
  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <div>
    <a:documentation>CONTENT MODEL AND ATTRIBUTE LIST OVERRIDES</a:documentation>
    <include href="urn:pubid:oasis:names:tc:dita:rng:topicMod.rng:2.0">
      <define name="topic-info-types">
        <ref name="topic.element"/>
      </define>
      <define name="p.attributes" combine="interleave">
        <optional>
          <attribute name="otherprops"/>
        </optional>
      </define>
      <define name="div.attributes" combine="interleave">
        <optional>
          <attribute name="otherprops"/>
        </optional>
      </define>
      <define name="section.attributes" combine="interleave">
        <optional>
          <attribute name="otherprops"/>
        </optional>
      </define>
    </include>
  </div>
</grammar>
  2. They then update the catalog.xml file to include the expansion module.

  3. They integrate the extension module into the applicable document-type shell, and remove the <include> element for topicMod.rng:

      <div>
    <a:documentation>ELEMENT-TYPE CONFIGURATION INTEGRATION</a:documentation>
      <include href="acme-otherpropsAttExpansion.rng"/>
  </div>
  <div>
    <a:documentation>MODULE INCLUSIONS</a:documentation>
    <include href="urn:pubid:oasis:names:tc:dita:rng:topicMod.rng:2.x"/>
    ...
    <include href="urn:pubid:oasis:names:tc:dita:rng:otherpropsAttDomain.rng:2.0">
    </include>
  </div>

  4. They remove the reference to the @otherprops attribute from the props-attribute-extension pattern:

      <div>
    <a:documentation>MODULE INCLUSIONS</a:documentation>
      ...
    <include href="urn:pubid:oasis:names:tc:dita:rng:otherpropsAttDomain.rng:2.0">
      <define name="props-attribute-extensions" combine="interleave">
      <empty/>
      </define>
    </include>

  5. They ensure that the included-domains entity contains the @otherprops contribution to the @specializations attribute: 

      <div>
    <a:documentation>SPECIALIZATIONS ATTRIBUTE</a:documentation>
    <define name="specializations-att">
      <optional>
        <attribute name="specializations" a:defaultValue="
                         @props/audience
                         @props/deliveryTarget
                         @props/otherprops
                         @props/platform
                         @props/product"/>
      </optional>
    </define>
  </div>
  6. After checking the test topic to ensure that the attribute lists are modified as expected, the work is done.

Example: Aggregating constraint and expansion modules using RNG

This section is non-normative.

The DITA architect wants to add some extension modules to the document-type shell for topic. The document-type shell already integrates a constraint module.

The following table lists the constraint module and the extension modules that the DITA architect wants to integrate into the document-type shell for topic.

Type of element configuration File name What it does
Constraint topicSectionConstraint.rng

Constrains <topic>:

  • Removes <abstract>
  • Makes <shortdesc> required
  • Removes <related-links>
  • Disallows topic nesting

Constrains <section>:

  • Makes @id required
Expansion sectionExpansionMod.rng Adds <sectionDesc> to the content model of <section>
Expansion tableCellAttExpansion.rng Adds @cellPurpose to the attribute lists for certain table elements

Because all of these element-configuration modules target elements declared in topicMod.rng, the DITA architect needs to combine them into a single element-configuration module like the following:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="urn:pubid:oasis:names:tc:dita:rng:vocabularyModuleDesc.rng"
                         schematypens="http://relaxng.org/ns/structure/1.0"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
  xmlns:dita="http://dita.oasis-open.org/architecture/2005/"
  xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
  datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <div>
    <a:documentation>CONTENT MODEL AND ATTRIBUTE LIST OVERRIDES</a:documentation>
    <include href="urn:pubid:oasis:names:tc:dita:rng:topicMod.rng:2.0">
      <!-- Redefines attribute list for section: Makes @id required -->
      <define name="section.attributes">
        <attribute name="id">
          <data type="ID"/>
        </attribute>
        <ref name="conref-atts"/>
        <ref name="select-atts"/>
        <ref name="localization-atts"/>
        <optional>
          <attribute name="outputclass"/>
        </optional>
      </define>
      <!-- Adds sectionDesc to the content model of section -->
      <define name="section.content">
        <optional>
          <ref name="title"/>
        </optional>
        <optional>
          <ref name="sectionDesc"/>
        </optional>
        <zeroOrMore>
          <ref name="section.cnt"/>
        </zeroOrMore>
      </define>
      <!-- Adds @cellPurpose to certain table and simple table elements -->
      <define name="colspec.attributes" combine="interleave">
        <optional>
          <attribute name="cellPurpose"/>
        </optional>
      </define>
      <define name="entry.attributes" combine="interleave">
        <optional>
          <attribute name="cellPurpose"/>
        </optional>
      </define>
      <define name="row.attributes" combine="interleave">
        <optional>
          <attribute name="cellPurpose"/>
        </optional>
      </define>
      <define name="stentry.attributes" combine="interleave">
        <optional>
          <attribute name="cellPurpose"/>
        </optional>
      </define>
      <define name="strow.attributes" combine="interleave">
        <optional>
          <attribute name="cellPurpose"/>
        </optional>
      </define>
      <!-- Redefines topic: removes abstract and related-links; makes shortdesc -->
      <!--                  required; disallows topic nesting                   -->
      <define name="topic.content">
        <ref name="title"/>
        <ref name="shortdesc"/>
        <optional>
          <ref name="prolog"/>
        </optional>
        <optional>
          <ref name="body"/>
        </optional>
      </define>
    </include>
  </div>
</grammar>

When the DITA architect edits the document-type shell to integrate the element configuration module, they also need to do the following:

  • Remove the include statement for topicMod.rng
  • Add <section> to the "ID-DEFINING ELEMENT OVERRIDES" division