Ditaval Processing Order Different for Maps vs Transform

[Maquese]

Hello,

I'm having an issue with the ditaval being processed at a different time depending on whether the ditaval is included in the map or if it's included as an argument in the transformation.

The content that has profiling assigned to it is shared content and some of the topics are used by another product (which includes links that are not part of my project). When the output is generated with the ditaval specified as an argument in the transformation, everything generates fine with no issues. When the output is generated with the ditaval referenced within the ditamap, I receive errors that Oxygen can't find content that should have been filtered out by the ditaval.

In the transformation, the argument

Code: Select all

filter-stage

is set to "early" which appears to be why it works (setting it to "late" produces the same errors that content cannot be found). Is there a way to get Oxygen to filter "early" when using the ditaval file in the map rather than specifying it in the transformation? Is there a recommended place in the map to reference the ditaval file?

The issues we're trying to work out is that our users have to create copies of our transformation templates for each output type and ditaval file. It would be a lot cleaner/simpler for our users to just reference the ditaval in their maps.

Thanks!
Mark

[Radu]

Hi Mark,

Indeed the DITA Open Toolkit publishing engine used by Oxygen to produce output from DITA content might behave differently if the DITAVAL is provided in the command line versus using the <ditavalref> DITA 1.3 feature to specify it internally. It's not exactly a bug because the DITA 1.3 specification does not explicitly state that the two means are equivalent.
There are various issues registered on the publishing engine related to ditavalref:

https://github.com/dita-ot/dita-ot/issu ... ditavalref

and in a case like yours in which you are using it just for convenience, I would suggest you stick to using the command line parameter.

About your need for it:

The issues we're trying to work out is that our users have to create copies of our transformation templates for each output type and ditaval file. It would be a lot cleaner/simpler for our users to just reference the ditaval in their maps.

If you edit an Oxygen transformation scenario, in the "Filters" tab you can specify the path to the DITAVAL file. The path can use editor variables to refer to the DITAVAL file, something like for example: "${rootMapDirURL}/path/to/custom.ditaval" where the ${rootMapDirURL} should be automatically resolved to the folder where the current published DITA map is located.
More about editor variables:

https://www.oxygenxml.com/doc/versions/ ... ables.html

Regards,
Radu

[Maquese]

Hi Radu,

Thanks for the response! I'll pass along the information about using relative folder paths for a custom ditaval so we can do some internal testing.

I agree with your assessment that the difference in processing order is not a bug, but perhaps a future enhancement to allow users to either specify the processing order globally in Oxygen or to apply the filter-stage setting from the transform regardless of whether the ditaval is specified directly in the map or through the filters tab on the transform itself.

Thanks,
Mark