Project

Profile

Help

creating multiple files in XSLT 2.0?

Added by Anonymous over 16 years ago

Legacy ID: #4728408 Legacy Poster: Ke Xu (kexu2000)

After reading the following IBM article: http://www.ibm.com/developerworks/xml/library/x-tipmultxsl.html I realized that the Saxon XSLT 2.0 api has the capability of creating multiple output files from a single input xml file. We are trying to basically perform a backend transformation of this nature with Java. I haven’t been able to find an example code of doing this anywhere on the web. I was wondering if you have such an example with the Saxon api? So to do this for a single xml input to output transformation, I would have the following code: // 1. Instantiate a TransformerFactory. javax.xml.transform.TransformerFactory tFactory = javax.xml.transform.TransformerFactory.newInstance(); // 2. Use the TransformerFactory to process the stylesheet Source and // generate a Transformer. javax.xml.transform.Transformer transformer = tFactory.newTransformer (new javax.xml.transform.stream.StreamSource(xsltFileName)); // 3. Use the Transformer to transform an XML Source and send the // output to a Result object. transformer.transform ( new javax.xml.transform.stream.StreamSource(xmlFileName), new javax.xml.transform.stream.StreamResult( new java.io.FileOutputStream("c:/opt/ sample_output.xml")) ); Is there a similar example using Saxon with XSLT 2.0 to produce multiple output files? Sincerely,


Replies (1)

RE: creating multiple files in XSLT 2.0? - Added by Anonymous over 16 years ago

Legacy ID: #4728483 Legacy Poster: Michael Kay (mhkay)

The only difference at the Java level is that the Result destination for the principal output must have a known URI. When you call new javax.xml.transform.stream.StreamResult( new java.io.FileOutputStream("c:/opt/ sample_output.xml")) the SystemId of the Result object isn't set, so Saxon doesn't know where the principal output is going, so it can't resolve a relative URI appearing in the href attribute of xsl:result-document. If you use a different constructor: new javax.xml.transform.stream.StreamResult( new java.io.File("c:/opt/ sample_output.xml")) this problem should go away. The Java application doesn't need to do anything about the secondary output files, they will simply be written relative to the primary output. It can be useful to set the -t option (the equivalent from Java is called FeatureKeys.TIMING) to display where the output files have been written. If you want more detailed control you can nominate an OutputURIResolver, but I doubt you need it.

    (1-1/1)

    Please register to reply