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.ditaval
andnovice.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-novice.dita
. There is no renaming based onlinux.ditaval
, and the <ditavalref> the referencesnovice.ditaval
adds thesuffix -novice
. - The second instance is filtered using the conditions in
linux.ditaval
andadvanced.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-admin.dita
. There is no renaming based onlinux.ditaval
, and the <ditavalref> that referencesadvanced.ditaval
adds the suffix-admin
. - The third instance is filtered using the conditions in
mac.ditaval
andnovice.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-novice-mac.dita
. The <ditavalref> that referencesnovice.ditaval
adds the suffix-novice
, resulting inconfigure-novice.dita
, and then the <ditavalref> that referencesmac.ditaval
adds the additional suffix-mac
. - The fourth instance is filtered using the conditions in
mac.ditaval
andadvanced.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-admin-mac.dita
. The <ditavalref> that referencesadmin.ditaval
adds the suffix-admin
, resulting inconfigure-admin.dita
, and then the <ditavalref> that referencesmac.ditaval
adds the additional suffix-mac
. - The fifth instance is filtered using the conditions in
win.ditaval
andnovice.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-novice-win.dita
. The <ditavalref> that referencesnovice.ditaval
adds the suffix-novice
, resulting inconfigure-novice.dita
, and then the <ditavalref> that referenceswin.ditaval
adds the additional suffix-win
. - The sixth instance is filtered using the conditions in
win.ditaval
andadvanced.ditaval
. For this instance, the resourceconfigure.dita
is treated as the resourceconfigure-admin-win.dita
. The <ditavalref> that referencesadmin.ditaval
adds the suffix-admin
, resulting inconfigure-admin.dita
, and then the <ditavalref> that referenceswin.ditaval
adds the additional suffix-win
.