[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

XSL-FO result tree structure design

Subject: XSL-FO result tree structure design
From: Michael Friedman <sumarimike@xxxxxxxxx>
Date: Thu, 24 May 2012 11:51:42 -0500
 XSL-FO result tree structure design
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

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

Example 1: The Russian Doll
          <para>A lonely para in a cruel sect2.</para>

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>

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
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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.