Child navigation links to nested topics are incorrect/missing if there is a <ph keyref/>

[chrispitude]

Actual Behavior

When all of the following are true:

• A topic file that has nested subtopics in the same file.
• This topic file is included in two different submaps (content reuse).
• Both submaps are included (in different keyscopes) in the same top-level map.
• The topic file contains a <ph keyref="..."/> reference.

then if I run the html5 transformation, the child navigation links for the second submap's topic instance are missing, which causes all child links to point to the top-level topic instead of the nested topics:

• Feature Topic
  • Concepts
  • Configuration
    • Option 1
    • Option 2
  • Limitations
• Feature Topic
  • Feature Topic (incorrect)
  • Feature Topic (incorrect)
    • Feature Topic (incorrect)
    • Feature Topic (incorrect)
  • Feature Topic (incorrect)

If I run the pdf2 transformation instead of the html5 transformation (which uses preprocess2 instead of preprocess), then I get an even weirder result of recursively nested links that are a mix of correct and incorrect links.

Expected Behavior

Child links should resolve correctly, whether there is a <ph keyref="..."/> or not.

If the <ph keyref="..."/> element is deleted, then the child navigation links are gathered correctly:

• Feature Topic
  • Concepts
  • Configuration
    • Option 1
    • Option 2
  • Limitations
• Feature Topic
  • Concepts
  • Configuration
    • Option 1
    • Option 2
  • Limitations

Possible Solution

I am not sure yet, but I will follow up if I figure something out.

Steps to Reproduce

1. Extract the following testcase:
   incorrect_nested_topic_links.zip
2. Run the following command in the testcase directory:
   dita -i map.ditamap -f html5 -o out
3. View the index.html file in a browser and note the incorrect links.

Environment

• DITA-OT version: 3.7.0
• Operating system and version:
  linux
• How did you run DITA-OT?
  dita command
• Transformation type:
  html5, pdf2

[chrispitude]

The issue occurs in this part of the keyref preprocessing step:

    <pipeline message="Resolve keyref." taskname="keyref">
      <module class="org.dita.dost.module.KeyrefModule" parallel="${parallel}">
        <param name="transtype" value="${transtype}"/>
      </module>
    </pipeline>

In the "good" case (no <ph keyref="..."/> in the topic file), the map is as follows:

<map>
  <title>Online Help</title>
  <submap keyscope="submap1">
    ...
    <topicref href="topic.dita">
      <topicref href="topic.dita#concepts"/>
      <topicref href="topic.dita#configuration">
        <topicref href="topic.dita#option1"/>
        <topicref href="topic.dita#option2"/>
      </topicref>
      <topicref href="topic.dita#limitations"/>
    </topicref>
  </submap>
  <submap keyscope="submap2">
    ...
    <topicref href="topic.dita">
      <topicref href="topic.dita#concepts"/>
      <topicref href="topic.dita#configuration">
        <topicref href="topic.dita#option1"/>
        <topicref href="topic.dita#option2"/>
      </topicref>
      <topicref href="topic.dita#limitations"/>
    </topicref>
  </submap>
</map>

In the "bad" case (topic file contains a <ph keyref="..."/>), the map is as follows:

<map>
  <title>Online Help</title>
  <submap keyscope="submap1">
    ...
    <topicref href="topic.dita">
      <topicref href="topic.dita#concepts"/>
      <topicref href="topic.dita#configuration">
        <topicref href="topic.dita#option1"/>
        <topicref href="topic.dita#option2"/>
      </topicref>
      <topicref href="topic.dita#limitations"/>
    </topicref>
  </submap>
  <submap keyscope="submap2">
    ...
    <topicref href="topic-1.dita">
      <topicref href="topic-1.dita"/>
      <topicref href="topic-1.dita">
        <topicref href="topic-1.dita"/>
        <topicref href="topic-1.dita"/>
      </topicref>
      <topicref href="topic-1.dita"/>
    </topicref>
  </submap>
</map>

It looks like the keyref causes the second topic file to be duplicated to topic-1.dita, but the subtopic ID suffixes are not preserved during the duplication.

Unfortunately the issue is inside the org.dita.dost.module.KeyrefModule Java module, which is beyond my ability to understand or fix.

[chrispy-snps]

I think the @href rename might be in the walkMap() function in

https://github.com/dita-ot/dita-ot/blob/develop/src/main/java/org/dita/dost/module/KeyrefModule.java

but I don't know enough Java to follow exactly how the rename is performed or how the URI fragment should be preserved.

[raducoravu]

In the method "org.dita.dost.module.KeyrefModule.walkMap" there is a call to "stripFragment" which probably is the one removing the anchor.
Maybe the fragment can first be preserved in a variable before it is stripped:

                            URI resolved = map.uri.resolve(referenceValue);
                        	String frag = resolved.getFragment();
                            final URI href = stripFragment(resolved);

and then further down in the two places where the referenceValue is computed add the anchor back if it originally was there.

                                        referenceValue = value.toString();
                                        if(frag != null && ! referenceValue.contains("#")) {
                                        	referenceValue += "#" + frag;
                                        }

[chrispy-snps]

@raducoravu - this worked perfectly on the testcase!

I'll do more testing on larger books in our collection. If everything looks good, I'll submit a pull request. Thank you!

[jlacour31]

@jelovirt and @infotexture it seems that the pull request was merged into develop branch and not in hotfixes/3.7.1. So the fix is not available neither in DOT 3.7.1 nor 3.7.2. You should consider cherry picking this fix for a 3.7.3 and updating the release notes to remove the reference to this fix.

[infotexture]

@jlacour31 Thanks for bringing this to our attention.

I've ported the original fix from #3874 to 3.7.3 with #3945 and updated the 3.7.1 Release Notes in the dev docs to remove this issue reference. (The 3.7 docs will be updated when we release 3.7.3.)