The answer is that (a) the first transformation is very expensive in time relative to the second (typically a factor of 20), and (b) I don’t need to perform the first stage transformation very often, but I do the second (which will vary depending on the operation invoked). What I don’t want to do is to keep invoking the first transformation, and therefore I adopted the approach of holding the result of the first stage transformation in memory (although I could have obviously written this to disk).

This worked fine with the raw ByteArrayInput/OutputStream classes, but when I sought to optimize the storage of this data, I’ve run into this rather unobvious problem.


On 15/06/2008 21:58, "Michael Kay" <mike@saxonica.com> wrote:

I don't know why this is happening, but my first reaction is, I don't know
why you are taking this approach. The second transformation is going to
build its input document into a tree in memory; this tree will occupy about
5 times the size of the byte array, so compressing the byte array is not
going to help very much. It would be far better to dispense with the byte
array entirely and have the first transformation write its output to a tree
which the second transformation can use directly. This also saves you the
serialization and parsing costs, which can take as long as the
transformation itself.

The class XsltTransformer implements the Destination interface, so you can
simply use the second XsltTransformer as the destination of the first.

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: saxon-help-bounces@lists.sourceforge.net
> [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf
> Of Jackson, Bruce
> Sent: 15 June 2008 18:02
> To: saxon-help@lists.sourceforge.net
> Subject: [saxon] Using Saxon 9B with
> DeflaterOutput/InflaterInput Streams
>
> In some code I'm writing, I'm doing a 2-stage transform using Saxon.
> First, I read an base XML document and transform it into an
> intermediate XML format. I then wish to hold this
> intermediate form in memory and perform a second
> transformation on it into the final form. The nature of this
> second transformation will depend on which particular method
> is called on my
> client: for each method, I have a corresponding transformer object.
>
> The intermediate in-memory document may well be large, hence
> I thought it would be a good idea to hold it in a compressed
> form, which leads me to my problem.
>
> I have the following method to compress the base XML document
> into the intermediate form:
>
> synchronized void transformLibrary() {
>
>     ByteArrayOutputStream buffer = new ByteArrayOutputStream();
>     DeflaterOutputStream dos = new DeflaterOutputStream(buffer);
>     Serializer destination = new Serializer();
>     destination.setOutputStream(dos);
>     transformer.setDestination(destination);
>
>         try {
>
>             transformer.setSource(iTunesSource);
>             transformer.transform();
>             data = buffer.toByteArray();
>
>         } catch(SaxonApiException sx) {
>
>             sx.printStackTrace();
>
>         }
> }
>
> And then fetch it back out again as the source for the second
> transformation:
>
> synchronized public StreamSource getSource() {
>
>     InflaterInputStream iis = new InflaterInputStream(
>         new ByteArrayInputStream(data));
>     return new StreamSource(iis);
>
> }
>
> When I run the code, the first call (to transformLibrary())
> works without complaint. However, when I perform the second
> transform by calling getSource(), I get the following:
>
> Error on line 1 column 1758323
>   SXXP0003: Error reported by XML parser:
> Premature end of file.
> net.sf.saxon.s9api.SaxonApiException:
> org.xml.sax.SAXParseException: Premature end of file.
>     at
> net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:288)
>     at
> net.sf.saxon.s9api.XsltTransformer.setSource(XsltTransformer.java:106)
>
> I've scratched my head on this once, because (obviously) I've
> tried this directly onto a ByteArrayInput/OutputStream
> without the compression classes, and it works great. Thus, it
> appears that something in Saxon is causing a problem with the
> compression classes (or I'm being a complete dullard...).
>
> Any thoughts?
>
>
>
> --------------------------------------------------------------
> -----------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about
> anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> saxon-help mailing list archived at
> http://saxon.markmail.org/ saxon-help@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/saxon-help


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help