On Tue, Nov 23, 2010 at 4:42 PM, Dawid Chodura <dawid.chod...@gmail.com> wrote: > I want to transform an XML document, but I can't use XSLT, because > I need to invoke Java code inside the transformation.
I believe you need to make appropriate design and architectural decisions for your use-case. Personally I find XSLT's template based abstractions quite useful for XML document transformations. > If I understand correctly, Xalan is not an option. As Michael wrote Xalan provides Java extensions (you can virtually use any built-in Java API, or even write your own Java methods which you can invoke from XSLT stylesheets. XSLT transformations potentially get infinitely extensible procedurally with Java extensions). I personally would have gone this route first for this kind of use-case. > I don't need to keep the whole XML > document in the memory for the transformation, so I decided to use SAX > parser instead of DOM. You may try to tune JVM heap size while doing XSLT transforms, which generally helps to use memory efficiently during XSLT transformations. I normally try to have a good logical design for application (for example in your kind of use-case, using XSLT may be better than doing a SAX to SAX transformation) before worrying too much about physical memory that's available in computer host systems :) Imagine a huge XML transformation use-case. Though SAX to SAX transformation will probably save physical memory during application's run-time, but using XSLT for example can save numerous design hours and would help maintainability too. > What is the proper way to transform the stream of SAX events into > another stream of SAX events. I would suggest to have a little design thinking, before embarking this route :) -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
