Example: <ditavalref> within a branch that already uses <ditavalref>
In the following map fragment, a set of operating system conditions applies to installation instructions. Within that common branch, a subset of content applies to different audiences.
<topicref href="install.dita">
<ditavalref href="linux.ditaval"/>
<ditavalref href="mac.ditaval">
<ditavalmeta>
<dvrResourceSuffix>-mac</dvrResourceSuffix>
</ditavalmeta>
</ditavalref>
<ditavalref href="win.ditaval">
<ditavalmeta>
<dvrResourceSuffix>-win</dvrResourceSuffix>
</ditavalmeta>
</ditavalref>
<topicref href="perform-install.dita">
<!-- other topics-->
</topicref>
<!-- Begin configuration sub-branch -->
<topicref href="configure.dita">
<ditavalref href="novice.ditaval">
<ditavalmeta>
<dvrResourceSuffix>-novice</dvrResourceSuffix>
</ditavalmeta>
</ditavalref>
<ditavalref href="advanced.ditaval">
<ditavalmeta>
<dvrResourceSuffix>-admin</dvrResourceSuffix>
</ditavalmeta>
</ditavalref>
<!-- Other config topics -->
</topicref>
<!-- End configuration sub-branch -->
</topicref>
In this case, the effective map contains three copies of the complete
branch. The branches are filtered by operating system. Because topics in the branch
are
filtered in different ways, processors are effectively required to handle three copies
of
the entire branch. The map author uses the <dvrResourceSuffix>
elements to control naming for each copy. The Linux branch does not specify a
<dvrResourceSuffix> element, because it is the default copy of the
branch; this allows documents such as install.dita to retain their
original names.
Within each operating system instance, the configuration sub-branch is repeated; it is filtered once for novice users and then again for advanced users. As a result, there are actually six instances of the configuration sub-branch. Additional <dvrResourceSuffix> elements are used to control naming for each instance.
- The first instance is filtered using the conditions in
linux.ditavalandnovice.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-novice.dita. There is no renaming based onlinux.ditaval, and the <ditavalref> the referencesnovice.ditavaladds thesuffix -novice. - The second instance is filtered using the conditions in
linux.ditavalandadvanced.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-admin.dita. There is no renaming based onlinux.ditaval, and the <ditavalref> that referencesadvanced.ditavaladds the suffix-admin. - The third instance is filtered using the conditions in
mac.ditavalandnovice.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-novice-mac.dita. The <ditavalref> that referencesnovice.ditavaladds the suffix-novice, resulting inconfigure-novice.dita, and then the <ditavalref> that referencesmac.ditavaladds the additional suffix-mac. - The fourth instance is filtered using the conditions in
mac.ditavalandadvanced.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-admin-mac.dita. The <ditavalref> that referencesadmin.ditavaladds the suffix-admin, resulting inconfigure-admin.dita, and then the <ditavalref> that referencesmac.ditavaladds the additional suffix-mac. - The fifth instance is filtered using the conditions in
win.ditavalandnovice.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-novice-win.dita. The <ditavalref> that referencesnovice.ditavaladds the suffix-novice, resulting inconfigure-novice.dita, and then the <ditavalref> that referenceswin.ditavaladds the additional suffix-win. - The sixth instance is filtered using the conditions in
win.ditavalandadvanced.ditaval. For this instance, the resourceconfigure.ditais treated as the resourceconfigure-admin-win.dita. The <ditavalref> that referencesadmin.ditavaladds the suffix-admin, resulting inconfigure-admin.dita, and then the <ditavalref> that referenceswin.ditavaladds the additional suffix-win.