Using DITA-OT project files for conditional books

[Chris Papademetrious]

(resending with typos fixed)

Hi everyone,

I would like to use DITA-OT project files to define and manage deliverables, but I'm running into issues when I try to use them for our content. In this post, I will share my experiences and hopefully get some discussion going (and more hopefully, move toward solutions!).

1. Can't control PDF output name from <deliverable>

We publish multiple PDFs from the same map via @product profiling and DITAVAL files. We use the outputFile.base parameter to control the output PDF file name. For example,

dita --input=prod_ug.ditamap --format=pdf \

  --filter=filter_prodA.ditaval \

  -DoutputFile.base=prodA_ug

dita --input=prod_ug.ditamap --format=pdf \

  --filter=filter_prodB.ditaval \

  -DoutputFile.base=prodB_ug

Unfortunately, the <deliverable> element does not provide a corresponding way to control the output filename. I can set the outputFile.base argument from the <publication> element, but it is not practical to create hundreds of unique <publication> elements to capture each file name.

Has anyone run into this? I filed an enhancement request here.

2. Can't apply review/final DITAVAL flagging from <publication>

We have review and final PDF flavors, with DITAVAL files to flag @rev and @audience attributes accordingly:

dita --input=prod_ug.ditamap --format=pdf \
  --filter=filter_prodA.ditaval:flag_review.ditaval \
  -DoutputFile.base=prodA_ug

dita --input=prod_ug.ditamap --format=pdf \
  --filter=filter_prodA.ditaval:flag_final.ditaval \
  -DoutputFile.base=prodA_ug

Unfortunately when I configure a flagging DITAVAL file in a <publication>, it is ignored:

  <publication transtype="pdf2" id="pub-pdf-review">
    <param name="args.draft" value="yes"/>
    <param name="args.filter" value="flag_review.ditaval"/>
  </publication>
  <publication transtype="pdf2" id="pub-pdf-final">
    <param name="args.draft" value="no"/>
    <param name="args.filter" value="flag_final.ditaval"/>
  </publication>

Has anyone run into this? I filed an issue here.

I welcome any first-hand experience on these (or other!) DITA-OT project file topics. I also welcome any "armchair engineering" you'd like to engage in. :)

Thanks!

 - Chris

[Radu Coravu]

Hi Chris,

Your requests make sense, I added some ideas about workarounds for (1) and (2) here:

https://github.com/dita-ot/dita-ot/issues/3682#issuecomment-773073661

and here:

https://github.com/dita-ot/dita-ot/issues/3690#issuecomment-773075469

they are both related to the idea of XSLT processing the DITA OT project file to create a final DITA OT project file used to build the publication.

Regards,

Radu

--
You received this message because you are subscribed to the Google Groups "DITA-OT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dita-ot-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/dita-ot-users/c4f22e7f-d0f0-487e-9d26-5ce74ad98d53n%40googlegroups.com.

[Chris Papademetrious]

Hi Radu,

This is an interesting idea, thank you!

Can you think of a way to apply this XSLT within Oxygen's publishing environment, so it would be called on-the-fly when the user wants to publish a project-based deliverable?

 - Chris

[Chris Papademetrious]

Hi all,

For the following:

In project files, allow incremental <param> inside <publication idref="..."> #3682

the underlying issue is that each derivative of a conditional source map typically has its own name associated with it., and we need the output file name (PDFs in particular) to reflect this name. What's the best way to enhance DITA-OT project files to support this?

Should it be a first-class property of the <context> itself, then follow that context into the deliverables?

  <context id="context-ug1" name="User Guide 1">

    <input href="userguide-shared.ditamap"/>

    <profile>

      <ditaval href="cond1.ditaval"/>

    </profile>

    <basename value="userguide1"/>

  </context>

  <context id="context-ug2" name="User Guide 2">

    <input href="userguide-shared.ditamap"/>

    <profile>

      <ditaval href="cond2.ditaval"/>

    </profile>

    <basename value="userguide2"/>

  </context>

Should it be a first-class property of each <deliverable>, which allows it to be varied on a per-deliverable basis, such as to name PDFs differently for "review" and "final" deliverables?

  <deliverable id="del-pdf-ug1">
    <context idref="context-ug1"/>
    <basename value="userguide1-review"/>
    <publication idref="pub-pdf2-review"/>
  </deliverable>

  <deliverable id="del-pdf-ug2">
    <context idref="context-ug2"/>
    <basename value="userguide2-review"/>
    <publication idref="pub-pdf2-review"/>
  </deliverable>

Should it be a lower-level mechanical property instead of a first-class property?

  <deliverable id="del-pdf-ug1">

    <context idref="context-ug1"/>

    <publication idref="pub-pdf2-review">

      <param name="outputFile.base" value="userguide1-review"/>

    </publication>

  </deliverable>

  <deliverable id="del-pdf-ug2">

    <context idref="context-ug2"/>

    <publication idref="pub-pdf2-review">

      <param name="outputFile.base" value="userguide2-review"/>

    </publication>

  </deliverable>

I am particularly hoping to solicit philosophical feedback from the DITA-OT project file stakeholders (George? Jarno?), although feedback from everyone is welcomed!

 - Chris

[Radu Coravu]

Hi Chris,

Maybe you can take a look at the ANT build file Oxygen uses to start the DITA OT publishing on a DITA project:

OXYGEN_INSTALL_DIR/frameworks/dita/dita_project/build_dita_project.xml

Maybe you can create a similar ANT build file which also applies an XSLT transformation to produce the final DITA OT project file before starting the DITA OT "dita" command.

Regards,

Radu

To view this discussion on the web, visit https://groups.google.com/d/msgid/dita-ot-users/25f3837e-4839-4206-b359-5aa052efe0dbn%40googlegroups.com.