Subject: [xsl] XSL-FO result tree structure design From: Michael Friedman <sumarimike@xxxxxxxxx> Date: Thu, 24 May 2012 11:51:42 -0500 |
Greetings, I'm troubleshooting some timeout and memory errors in Arbortext 6.0 M010 publishing engine. The timeout errors, through a lot of testing, appear to be related to volume of content. Specifically, I have a list with numerous child lists that causes it to be long. I don't think the issue is actually with Arbortext, however, and taking a step back and looking at the structure of the XSLFO ouput has made me wonder about the design that we are using. The way I have experienced it, there are two possible ways of looking at XSLFO output. First, the way the stylesheets (FO 1.1) for my customer were designed, is the "Russian doll" approach. In this approach, a given chapter of content is the outer-most container. Sections are the next smallest container, followed by subsections, etc. So, we start with an XML structure: Example 1: The Russian Doll <chapter> <sect1> <sect2> <para>A lonely para in a cruel sect2.</para> </sect2> </sect1> </chapter> The transformed FO output reflects containers within containers within the body flow (I use the id for reading ease, not in actual output): <block id="chapter"> <block id="sect1"> <block id="sect2"> <block id="para">A lonely para in a cruel sect2.</block> </block> </block> </block> This looks simple enough until I add in a ton of content. By the time the chapter is actually being processed on live data, the largest chapter block is vast, and I am beginning to think that this may be why I am having memory and crashing problems. The second way is to create loose blocks, outside of other containing blocks, where possible. Example 2: Loose Blocks (I don't mean blocks that are immoral) - result FO: <block id="chapter"/> <block id="sect1"/> <block id="sect2"/> <block id="para">A lonely para in a cruel sect2.</block> Moving to this approach would require redesigning the stylesheets to recognize key elements, I think - I haven't thought down this road too far yet, and it may be moot to do so. Finally, my questions, based on the above, and my limited knowledge on how the Arbortext PE (and FO processors) work: 1) Is there a preferred method in result tree design that FO processors prefer, especially related to memory allocation or chunking? 2) Are there specific risks or benefits to using one of these two methods? 3) Are there other methods I am missing? Hybrid, etc. Kind regards, Michael Friedman
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Comparing direct ancestor, Ihe Onwuka | Thread | Re: [xsl] XSL-FO result tree struct, G. Ken Holman |
Re: [xsl] Comparing direct ancestor, Spencer Tickner | Date | Re: [xsl] Diagram of XPath axes, Imsieke, Gerrit, le- |
Month |