Example: <ditavalref>
within a branch that already uses
<ditavalref>
When a branch is filtered because a <ditavalref>
element is
present, another <ditavalref>
deeper within that branch can supply
additional conditions for a subset of the branch.
Example
<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 and novice.ditaval. For this
instance, the resource configure.dita is treated as the resource
configure-novice.dita. There is no renaming based on
linux.ditaval, and the
<ditavalref>
the references novice.ditaval adds thesuffix -novice
. - The second instance is filtered using the conditions in
linux.ditaval and advanced.ditaval. For this
instance, the resource configure.dita is treated as the resource
configure-admin.dita. There is no renaming based on
linux.ditaval, and the
<ditavalref>
that references advanced.ditaval adds the suffix-admin
. - The third instance is filtered using the conditions in mac.ditaval
and novice.ditaval. For this instance, the resource
configure.dita is treated as the resource
configure-novice-mac.dita. The
<ditavalref>
that references novice.ditaval adds the suffix-novice
, resulting in configure-novice.dita, and then the<ditavalref>
that references mac.ditaval adds the additional suffix-mac
. - The fourth instance is filtered using the conditions in mac.ditaval
and advanced.ditaval. For this instance, the resource
configure.dita is treated as the resource
configure-admin-mac.dita. The
<ditavalref>
that references admin.ditaval adds the suffix-admin
, resulting in configure-admin.dita, and then the<ditavalref>
that references mac.ditaval adds the additional suffix-mac
. - The fifth instance is filtered using the conditions in win.ditaval
and novice.ditaval. For this instance, the resource
configure.dita is treated as the resource
configure-novice-win.dita. The
<ditavalref>
that references novice.ditaval adds the suffix-novice
, resulting in configure-novice.dita, and then the<ditavalref>
that references win.ditaval adds the additional suffix-win
. - The sixth instance is filtered using the conditions in win.ditaval
and advanced.ditaval. For this instance, the resource
configure.dita is treated as the resource
configure-admin-win.dita. The
<ditavalref>
that references admin.ditaval adds the suffix-admin
, resulting in configure-admin.dita, and then the<ditavalref>
that references win.ditaval adds the additional suffix-win
.