Inserting a <br/> element in HTML for root topics

[jnielsen]

I have given a more detailed explanation of the issue I am having now on the dita forms (click here) if you want more details on this, but I am trying to insert a <br> element before topics that are at the root of a ditamap.

Through personal observation of dita2htmlImpl.xsl it appears that some conversion in the form of the source xml takes place from the original ditamap before it gets processed by dita2htmlImpl.xsl that gives all the topics a nested depth of zero, rendering ancestor::* and descendant::* checks useless, (to check this I printed the $nestlevel variable from the child.topic template - and its also evident because a condition to insert a <br> for "root" topics puts a <br> on all the topics), regardless of whether they were children (in the ditamap) of a root topic - they all had the same depth. This makes it difficult to do conditional processing for root nodes based on a depth comparison if all topics are at the same depth. As I said, you can see a more detailed explanation of my problem in that forum, but does anyone have a suggestion about how I might be able to accomplish what I am trying to do?

Also as a side note after studying the dita2htmlImpl.xsl file closely I'm still puzzled as to how the topics end up with a depth of zero, my only conclusion was that they were pre-processed in some way that made them that way, and also there is a /dita element that several templates match which was not present in the source ditamap, such as the template for matching the root context node <xsl:template match="/dita | /*[contains(@class,' topic/topic ')]" priority="1" name="root_element">. If there is an easy explanation I'd like to understand how these topics end up with the same depth. In addition is there any documentaion or otherwise that explains that process or is this just somethign that each DITA user has to figure out as they go along. I ask because I have a tendency to do things the hard way. A proper understandign of why that is happenign would be satisfying at any rate.

Thanks,

Josh

[jnielsen]

I'm also aware that chunking seems to be a partial remedy, but I don't understand what makes them all the same depth in the first place. Plus chunking is a nightmare for the Table of Contents and it causes several links to point to the same place and can do crazy things for recursive functions (like print a TOC section 10 times). So perhaps having a better understanding of what's going on will help me navigate around this a little better.

[Radu]

Hi Josh,

Indeed the XSL is applied on the pre-processed XML input.
So my recommandation remains the one in post http://www.oxygenxml.com/forum/topic3366.html.

You have to get the pre-processed XML content in a file and then you can check out its structure, debug it in Oxygen if you want. There are many stages in a DITA ANT transformation and you have to break down the problem.

Regards,
Radu

[jnielsen]

Hi Josh,

Indeed the XSL is applied on the pre-processed XML input.
So my recommandation remains the one in post http://www.oxygenxml.com/forum/topic3366.html.

You have to get the pre-processed XML content in a file and then you can check out its structure, debug it in Oxygen if you want. There are many stages in a DITA ANT transformation and you have to break down the problem.

Regards,
Radu

Thanks, that helps visualisation tremendously. I didn't consider using that to analyze this. Thanks for the pointer.

Josh