New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot conref from one submap to another #2494

Closed
raducoravu opened this Issue Sep 28, 2016 · 11 comments

Comments

Projects
3 participants
@raducoravu
Member

raducoravu commented Sep 28, 2016

I'm attaching a sample:

topicref-conref-problem.zip

Basically one submap conrefs to an ID set on a topicref in another submap. The conref is not expanded at all in the output.
In my opinion the problem is that the [conref] stage applies only on the submap which has the actual original conref, when in fact it should apply on all DITA Maps, because all DITA Maps have been expanded by the previous [mapref] stage.

@raducoravu

This comment has been minimized.

Member

raducoravu commented Sep 28, 2016

As a possible quick fix in "build_preprocess.xml" the target named "conref" besides having a fileset like this:

<ditaFileset conref="true"/>

could have an additional file set with all DITA Maps:

<ditaFileset format="ditamap"/>
@raducoravu

This comment has been minimized.

Member

raducoravu commented Sep 28, 2016

Or have two conref stages, one for DITA Maps which is applied before mapref, and one for topics which is applied later on...

@jelovirt

This comment has been minimized.

Member

jelovirt commented Sep 28, 2016

The correct fix is to update job configuration after map merge, to cascade conref flag up to the main map from submaps.

@robander

This comment has been minimized.

Member

robander commented Jan 3, 2018

@raducoravu or @jelovirt do you know if this might be fixed with preprocess2? If so it might still need to be open against preprocess but it would be nice if we've already made some progress.

@raducoravu

This comment has been minimized.

Member

raducoravu commented Jan 4, 2018

I tested but it still does not work with the default DITA OT 3.0.1 processing (which should be from what I know proprocess2).

@robander

This comment has been minimized.

Member

robander commented Jan 4, 2018

Just FYI -- preprocess2 is now the default for PDF, but not for XHTML / HTML5, so depending on your transform type you can still get either one.

@raducoravu

This comment has been minimized.

Member

raducoravu commented Jan 4, 2018

I did not know that, from what I remember I tried also with PDF and it did not work though.

@jelovirt

This comment has been minimized.

Member

jelovirt commented Jan 5, 2018

IMO the fix that after map merge we check the map files for conref is still the correct one, but the fix is a bit tricky because map merge is implemented with XSLT. Thus we have no simple post-tranformation hook where we can check whether @conref attributes have been added. If we change the code to not just use <pipeline><xslt>, then that cannot really go into a bug fix release due to the extend of the changes. So this should probably go to 3.1.

An alternative fix is to add processing to read all map files and recollect conref info, but that's an uglier hack. At one point I tried to add support for chaining XSLT and SAX in a pipeline module, but I didn't finish that due feature.

So we can either handle things in the Ant configuration (simplified):

<pipeline message="Resolve mapref in ditamap" taskname="mapref">
  <sax>
    <ditafileset format="ditamap"/>
    <xslt style="${dita.plugin.org.dita.base.dir}/xsl/preprocess/mapref.xsl" filenameparameter="file-being-processed">
      <xmlcatalog refid="dita.catalog"/>
    </xslt>
    <filter class="org.dita.dost.writer.CollectConref"/>
  </sax>
</pipeline>

Or we use a dedicated module

<pipeline message="Resolve mapref in ditamap" taskname="mapref">
  <module class="org.dita.dost.module.MaprefModule">
    <param name="style" value="${dita.plugin.org.dita.base.dir}/xsl/preprocess/mapref.xsl"/>
  </module>
</pipeline>

@robander do you have a hard preference? If we go for the former, we need to keep developing the Ant layer DSL, but it's a big more reusable. The latter allows us to keep things simple and contained, and we require additional things, they are likely to be easier to add because we're at Java layer.

@robander

This comment has been minimized.

Member

robander commented Jan 5, 2018

No strong preference - sounds like there are advantages to both. It sounds like the latter approach with dedicated module might be slightly better because if other things like this come up in the future they'll be easier to handle. But yeah that would need to be for 3.1.

jelovirt added a commit to jelovirt/dita-ot that referenced this issue Jan 7, 2018

Move mapref process into own module dita-ot#2494
Signed-off-by: Jarno Elovirta <jarno@elovirta.com>

jelovirt added a commit to jelovirt/dita-ot that referenced this issue Jan 7, 2018

Collect conref and keyref information after mapref dita-ot#2494
Signed-off-by: Jarno Elovirta <jarno@elovirta.com>
@jelovirt

This comment has been minimized.

Member

jelovirt commented Jan 7, 2018

@robander #2875 fixes this. Are you able to review?

@robander

This comment has been minimized.

Member

robander commented Jan 8, 2018

@jelovirt reviewed -- fix looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment