cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "peter.gershkovich" <>
Subject Re: 64K barrier revisited
Date Thu, 12 Apr 2001 18:01:40 GMT
I tried another workaround by importing the same document and placing it 
into a variable:

<xsl:variable name="doc" select="document($path-param)"/>

all elements are accessed via
<xsl:apply-templates select="$doc/element"/>

The process is: XML --> XSP --> XSL(import doc) --> Output

So I have XSP processing what is necessary to handle dynamically and 
than import static content from the file.
Performance is fine so far.

Please correct me if my approach is flawed or has potential limitations.

Uli Mayring wrote:

> Hello,
> just ran into the infamous 64K barrier again and this time I found no
> workaround and had to abandon XSP for that particular application.
> So now my app does a pure XML/XSLT/XSLFO/PDF workflow and I was able to
> generate a 134-page PDF from the XML. So far, so good.
> Then I made the XML a little more complex per element and Cocoon barfed -
> of course that little addition of complexity was multiplied by 134.
> So my question now is, how should I tune my pure XML code in order to save
> as much memory as I can? Should I use elements or attributes? By that 
> I mean, which one of these two options is better:
> <element>
> <name>foobar</name>
> <item><name>foo</name><function>bar</function></item>
> </element>
> or
> <element name="foobar">
> <item name="foo" function="bar"/>
> </element>
> And, should I minimize breadth or depth? Consider that I have a large
> number of these <element> objects and generate one page per object in the
> output PDF. Would it be more efficient to reduce the number of elements or
> should I rather reduce the element's complexity?
> Ulrich

Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message