Merging Multiple Nested Topic Files Together

Post here questions and problems related to editing and publishing DITA content.
chrispitude
Posts: 907
Joined: Thu May 02, 2019 2:32 pm

Merging Multiple Nested Topic Files Together

Post by chrispitude »

To restructure the topics in some portion of a map, we sometimes use the following approach:
  1. Merge those topic files into a single temporary topic file with nested subtopics.
  2. Rewrite/restructure the content, modifying the subtopic structure as needed.
  3. Split the restructured topic back into separate topic files.
I didn't see a built-in way to do #1 in Oxygen, so I tried copying <topicref> elements from a map file into a topic file:

copy_paste_topicref.gif
copy_paste_topicref.gif (135.62 KiB) Viewed 438 times

then running a refactoring operation to replace the topic references with the topic content:

Code: Select all

  <xsl:template match="topicref[ends-with(@href, '.dita')]">
    <xsl:variable name="topic-content" select="document(@href)" as="item()"/>
    <xsl:sequence select="$topic-content/*"/>
    <xsl:apply-templates select="*"/>
  </xsl:template>
When I run this refactoring operation in Oxygen, document() includes xmlns:ditaarch="http://dita.oasis-open.org/architecture/2005/" in its return result:

oxygen_diff.png
oxygen_diff.png (63.96 KiB) Viewed 441 times

But when I run this same stylesheet with Saxon from the command line:

Code: Select all

java -jar $SAXON_JAR -xsl:refactoring/resolve-topicrefs.xsl -s:OPENME3.dita
then the namespace is not added.

My guess is that Oxygen enhances document() to infer namespaces for known XML document types to improve robustness of XML processing. But in my case, I would like to omit the namespace.

Is there some XSLT directive (perhaps Oxygen-specific) to omit this namespace inference in document()? I was not able to find one. If not, I can add some additional processing to strip the namespace, but I would like to avoid that if I can.

A testcase is included:
oxygen_xslt_namespace.zip
(5.19 KiB) Downloaded 100 times

To run,
  1. Open the OPENME1.xpr file.
  2. Open the OPENME2.ditamap file in the DITA Maps Manager.
  3. Open the OPENME3.dita topic file.
  4. Copy some topic references from the DITA Maps Manager, then Paste as XML into OPENME3.dita and save.
  5. Run the "Replace <topicref> with <topic> content" refactoring operation on OPENME3.dita.
Thank you!
Last edited by chrispitude on Sun Sep 25, 2022 3:05 pm, edited 1 time in total.
chrispitude
Posts: 907
Joined: Thu May 02, 2019 2:32 pm

Re: Merging Multiple Nested Topic Files Together

Post by chrispitude »

Thanks to the information in this blog post:

Namespaces in XSLT - By Evan Lenz

I learned that copy-namespaces="no" can be used to avoid copying namespaces:

Code: Select all

  <xsl:template match="topicref[ends-with(@href, '.dita')]">
    <xsl:variable name="topic-content" select="document(@href)" as="item()"/>
    <xsl:copy-of select="$topic-content/*" copy-namespaces="no"/>
    <xsl:apply-templates select="*"/>
  </xsl:template>
I updated the testcase in the previous post with this fix.

Hopefully this refactoring operations helps anyone who similarly needs to merge multiple topic files into a single topic file!
Radu
Posts: 8992
Joined: Fri Jul 09, 2004 5:18 pm

Re: Merging Multiple Nested Topic Files Together

Post by Radu »

Hi Chris,

Thanks for detailing your experience.
XML refactoring ignores the schema references for the main processed XML files, as it was intended mostly as a way to change a file's contents.
When loading files using the document() function the schema references are taken into account so default attributes and namespace declarations end up being loaded along with the external document. I'm not sure if we should add an enhancement to also ignore the schema information when using the document() function. We do not know the purpose the end user has in mind for this, if they just want to query the loaded content loading the schema information is useful but if they want to use parts of the document() loaded content in the current XML document, then the schema information set should not be used.

Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
Post Reply