Re: [PHP-XML-DEV] Pipelined XSL

On Thu, 2003-03-13 at 07:20, Alexandru COSTIN wrote:
> > libxslt needs the whole document in the memory before processing. I'm
> > not sure, if there are XSLT-Processors out there, which can handle that
> > differently. Even Xalan has to read the whole Document (but not
> > necesseraly the whole thing at once into the memory, see
> > http://xml.apache.org/xalan-j/design/design2_0_0.html#stree dor some
> > detilas)
>     This stree would be great to be implemented. Let me explain what we
> really need to make things clearer.
>     We have an XML containing
>     <root>
>         <row>
>            <name>Christian</name>
>         </row>
>         <row>
>            <name>John</name>
>         </row>
>     </root>
> 
>     The XSL that transforms it contains basically a xsl:for-each on
> /root/row, and for each name creates a new node
>     <pdf:text width=100><xsl:value-of select="name"/></pdf:text>
> 
>     The new generated tree is then serialized by us to a PDF file directly.
> 
>     The problem is that we have some 500 pages reports that take 500 MB in
> the memory before generation. And I was thinking that we could do something
> like "incremental transformation" that transforms a part of the XML tree,
> then serves it to the Serializer, then frees the memory and continues with
> the transformation. (with a breaker per /root/row in our case). I know that
> PHP isn't designed for multithreading (which would be necessary in some
> "emulated" form at least), but this is an approach that would allow SAX like
> performance (in terms of memory) for DOM/XSL transformations.

I see your problem, but I don't have a solution. Neither libxslt nor
Sablotron nor any other c-based XSLT-processort out there supports sth
like that at the moment (i'm glad to hear otherwise). Therefore it's
very unlikely, that PHP will support that in the near future (Looking at
our resources here, I doubt there's someone who writes a new
XSLT-processors or changes one to do that....).

Does anyone know, how Axkit, resp. Perl handle this problem?

> > But I
> > think, the compression attribute was intented to use for compressing the
> > serialized XML Document. Compressing the tree in memory? Mmmh, would
> > definitively slow down performance and is IMHO not very practical.
>     Ok, I am just wondering.
>     As we've reached this huge memory requirement, we were wondering if
> there is anything else that could help us (the idea in that our current
> client has 2 GB, we can serve his transformations). But we might not be that
> fortunate for other clients.

Split your documents using SAX ;) But in terms of domxml, no, i don't
know of a solution for such big documents.

>     Otherwise, Lucian has developed a XSD validator in PHP, it will take an
> XML schema and create a PHP file that validates XML documents to match the
> schema. (we use DOMXML of course for most of the tasks :). It will be
> included in the next version of Krysalis.

Recently someone was looking for sth like that. I will tell him. :) Will
it be in the Open Source Release of KRysalis?

But one question: Why didn't you try to use the XSD Support of libxml2?
libxml2 has XML Schema support, there was just noone whic implemented
this into domxml till now (and i think it has RelaxNG support as will
since a few weeks)

>     I was also wondering about the DOMXML support in PHP on windows - are
> you aware of any leaks? When doing those huge transformations we end up with
> 80 MB "leftovers" in the Apache process (which fortunately go away when the
> process restarts (apache 1.3.27).

dunno. I'm not a windows user. I'd need an example to be able to reproduce it.

chregu