<dvrResourcePrefix>

The <dvrResourcePrefix> element specifies the prefix to use when constructing the effective file names or resource IDs of the resources that are referenced from within the map branch that is implied by the ancestor <ditavalref> element.

Processing expectations

For processing expectations related to this element, see Using metadata elements in the DITAVAL-reference domain.

Specialization hierarchy

The <dvrResourcePrefix> element is specialized from <data>. It is defined in the DITAVAL-reference domain module.

Content model

(Text | <text>)*

Contained by

<ditavalmeta>

Zero or more of the following

Contained by

Inheritance

+ topic/data ditavalref-d/dvrResourcePrefix

The <dvrResourcePrefix> element is specialized from <data>. It is defined in the ditavalref-domain module.

Attributes

The following attributes are available on this element: universal attributes (except for @conkeyref, which is removed for all elements in this domain) and @name.

For this element, the @name attribute has a default value of dvrResourcePrefix.

The following attributes are available on this element: universal attributes (except for @conkeyref which is removed for all elements in this domain) and the attributes defined below.

@name (data-element attributes)
Defines a name for the object.
For this element, the @name attribute has a default value of dvrResourcePrefix.

Example

This section is non-normative.

Draft comment: robander 25 September 2026
This comment applies to all four metadata elements in the <ditavalmeta> element.

Should these examples move into the architectural specification with other branch filter examples? These are not about the general filtering behavior, and each example is specific to the element described. Examples in the architectural specification all focus on filtering. However, these are clearly about processing impact, so might be better to group them with all of the other branch filtering examples in that section, and turn the example sections here into a reference - "See [branch filtering examples]".

If they do move, we would end up with 5 new example topics – one each for the impact on resource prefix/sufix + keyscope prefix/suffix, and another for the impact on resource IDs.

Example 1. How <dvrResourcePrefix> affects resource file names
The following code sample shows a simple branch with a parent and child topic, where the branch uses a <ditavalref> element and <dvrResourcePrefix>.
<topicref href="branch-01.dita">
  <ditavalref href="condition-01.ditaval">
    <ditavalmeta>
      <dvrResourcePrefix>cond01-</dvrResourcePrefix>
    </ditavalmeta>
  </ditavalref>
  <topicref href="topics/subtopic-01.dita"/>
</topicref>
After the <ditavalref> is evaluated:
  • The effective file name of the resource subtopic-01.dita is cond01-subtopic-01.dita.
  • The effective file name of resource branch-01.dita is cond01-branch-01.dita.
Example 2. How <dvrResourcePrefix> interacts with <resourceid>
The following code sample shows the same branch with a parent and child topic, but in this case the child topic specifies a deliverable anchor with <resourceid>.
<topicref href="branch-01.dita">
  <ditavalref href="condition-01.ditaval">
    <ditavalmeta>
      <dvrResourcePrefix>cond01-</dvrResourcePrefix>
    </ditavalmeta>
  </ditavalref>
  <topicref href="topics/subtopic-01.dita">
    <topicmeta>
      <resourceid appid="ae35-unit-fault" appid-role="deliverable-anchor"/>
    </topicmeta>
  </topicref>
</topicref>
After the <ditavalref> is evaluated:
  • The effective file name of the resource subtopic-01.dita is cond01-subtopic-01.dita.
  • The effective file name of resource branch-01.dita is cond01-branch-01.dita.
  • The effective value of @appid on <resourceid> for the child topic is cond01-ae35-unit-fault.