Oxygen XML Forum

Greetings,

I have a bookmap that references a map of keydef elements. The keydefs refer to files where I keep all of my keys. When I run my old XSLT based transformation scenario, this works fine. However, when I run the CSS based transformation scenario, no change to the DITA at all, all of the references fail. The PDF will often have the "spot" for the content, but the content doesn't get rolled into the output. It also spits out a big list of errors, all of which contain the error code [DOTX010E]: Unable to find target for conref="../../Concepts/con_ProdDesc.dita#ProdName".

My best guess is that for some reason there is an extra "../../" placed in front of every file path for some reason. It doesn't need this though because both the map containing all the keydefs and the bookmap that is being rendered are at the top level, and the .dita files containing the keys are are nested deeper in the folder structure. In other words, the filepath should be "Concepts/con_ProdDesc.dita#ProdName" not "../../Concepts/con_ProdDesc.dita#ProdName" .

Here are some vital statistics:

Oxygen Version: <oXygen/> XML Editor 20.1, build 2018061313
Base Transformation Scenario: com.oxygenxml.pdf.css
OS: Windows 10

Thanks,

Carlos

Hi Carlos,

Usually such problems occur if there are references to resources located outside of the main DITA Map folder, and there are two possible solutions for this:

https://www.oxygenxml.com/doc/versions/ ... -refs.html

If you open the main DITA Map in the DITA Maps Manager and use the "Validate and check for completeness" toolbar button there should be a checkbox called "Report references to resources outside of the DITA Map folder", if you check that and validate does it report any such warnings?

Regards,
Radu

So it's funny, when I hit the "Validate and Check for Completeness" button in the DITA maps manager, I do get two validation errors related to a reference outside the main DITA map folder, BUT... the error only occurs on a regular conref, as opposed to a conkeyref. I have one test conref in the map that calls another .dita file in the same map. However, I don't get any of those errors on my conkeyrefs, but they still don't work.

But like I said in my original post, I believe the issue is related to how the filepaths are constructed when the transformation scenario is run. The filepath it assigns to all conkeyrefs has this structure "../../[FolderContainingReferencedFile]/[FileReferenced.dita]". However, this is an inaccurate address. It shouldn't have that extra "../" It should be "../[FolderContainingReferencedFile]/[FileReferenced.dita]" because my folder structure looks like this.

Concepts
conceptA.dita
conceptB.dita
conceptC.dita
Tasks
taskA.dita
taskB.dita
taskC.dita
References
referenceA.dita
referenceB.dita
referenceC.dita
MainDitaMap.ditamap
keymap.ditamap


So as you can see, if I have a conkeyref in taskA.dita that references a key in conceptA.dita, it should only ever have to climb the folder tree by one level, not two, but the processor is giving it a filepath that moves up two levels by adding a second "../".

Hope this makes sense and thanks for the response.

Carlos

Hi Carlos,

Once you have references to outside resources in one place, this might break also other references, which are not to resources outside of the main DITA Map folder. So there is a possibility that those two conrefs to outside resources will cause the publishing engine to break other links or the you mentioned conkeyrefs.
Have you tried editing the Oxygen transformation scenario and in the Parameters tab setting the parameter "fix.external.refs.com.oxygenxml" to "true"? Does that fix the problem?
If not, if you can prepare a small test DITA project and send it to us (support@oxygenxml.com) I could try to have a look at it.

Regards,
Radu

Yup, That fixed it! I turned the fix.external.refs.com.oxygenxml to true and we are back in business.

One question though. How robust is this solution? Are there things I should know, cases where it doesn't work that you are aware of? I ask because the folder structure that we have to use will require having references to files that are "outside the scope" of the reference document. So we are not going to be able to get away with not having this fix work and that makes me a little nervous. Regardless though, we are back in business.

Thanks Radu!

Hi Carlos,

The "fix.external.references" parameter will work for publishing only from inside Oxygen. So if you plan to publish using the DITA Open Toolkit publishing engine from a command line (having some kind of automated publishing integration server for example) you will somehow need to have the published DITA Map on top of everything else, without external references outside of its folder. There is a DITA Open Toolkit parameter called "generate.copy.outer" which might also work from the command line but this would need to be tested.

Regards,
Radu