Branch filtering not working in OT 2.5.3?

Expected Behavior

I have a small project which I’m using as a POC of branch filtering. In this example, I use @conkeyref to bring in the content I require. Each branch has a different ditavalref which should filter out the content excluded by the @product value.

Actual Behavior

All of the content that should be filtered out on a particular branch is not being filtered out. Looking at the temp files, the content is brought in. Global filtering appears to be working. This fails even if I use a simple conref, so it appears as if filtering is not being invoked for each branch. branch_filter_example.zip

Possible Solution

Steps to Reproduce

1. Unzip the attached test files
2. Run dita -i branch_filter_example -f html5
3. Launch the resulting output file

Copy of the error message, log file or stack trace

Environment

• DITA-OT version: 2.5.3
• Operating system and version: Windows 10 (Linux, macOS, Windows)
• How did you run DITA-OT? oXygen 19 and command line (dita command, Ant, startcmd, oXygen, other editor, CMS, etc.)
• Transformation type: webhelp on oXygen, HTML5 in command line. (HTML5, PDF, custom, etc.)

[lionelmoi]

The behavior you are describing seems to be normal.

Branch-filtering happens before key resolution (see http://www.dita-ot.org/2.5/dev_ref/DITA-OTPreprocess.html).

Your <ditavalrefs> elements are nested under <topicrefs> pointing to topics where no @product attributes are used.

    <topicref href="first_branch.dita" keys="branch_1">
        <ditavalref href="product_a.ditaval"/>
        <topicref href="new_topic.dita" keys="new_topic"/>
        <topicref href="second_topic.dita"/>
    </topicref>
    [...]

Nothing is profiled in first_branch.dita

When Branch-filtering happens nothing is filtered because nothing is profiled.

You profiled things in your keydef.

    <keydef keys="reusable" href="concept_reuse.dita"/>

But the <ditavalref> does not apply here.

There are several strategies to make it work.

The easiest one would be to profile in the <topicref>:

<concept id="new_topic">
    <title>
        <ph conkeyref="reusable/filtered_product_name" product="producta"/>
        <ph conkeyref="reusable/filtered_product_nameb" product="productb"/> Description</title>
    [...]

Another solution, maybe more elegant :

1. Nest the reused concept in each branch and add a @keyscope to each branch.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA 1.3 Map//EN" "map.dtd">
<map>
    <title>Branch filtering</title>
    <topicref href="first_branch.dita" keyscope="a">
        <ditavalref href="product_a.ditaval">
            <ditavalmeta>
                <dvrResourceSuffix>-a</dvrResourceSuffix>
            </ditavalmeta>
        </ditavalref>
        <topicref href="new_topic.dita" keys="new_topic"/>
        <topicref href="second_topic.dita"/>
        <keydef keys="reusable" href="concept_reuse.dita"/>
    </topicref>
    <topicref href="first_branch.dita" keyscope="b">
        <ditavalref href="product_b.ditaval">
            <ditavalmeta>
                <dvrResourceSuffix>-b</dvrResourceSuffix>
            </ditavalmeta>
        </ditavalref>
        <topicref href="new_topic.dita" keys="new_topic2"/>
        <topicref href="second_topic.dita"/>
        <keydef keys="reusable" href="concept_reuse.dita"/>
    </topicref>    
</map>

Note the <ditavalmeta> adding a suffix to the duplicated resources.

1. Nest all different version of the filtered_product_name under inside a <ph > element with the @id.

    <ph id="filtered_product_name">
        <ph product="producta">Product A</ph>
        <ph product="productb">Product B</ph>
    </ph

This way you only need <ph conkeyref="reusable/filtered_product_name"/> to refer to the filtered product name.

Since the keydef is in the branch, it is filter during Branch-filtering and when the Keyrefs are resolved only the filtered product name remains.

Working ditamap and file: branch_filter_example-keyscopes.zip

There are other ways but I think I will make a pull-request in the doc repo rather than a response to this thread 😃

[juliovaz]

I appreciate the clarifications. I guess that I should have looked at the OT documentation about the implementation as the spec doesn’t address the order of resolution.