1

I have multiple XSLT files that I'm using to process my source XML in a pipeline. I know about the trick with exsl:node-set but after having some issues with this workflow, I took the decision to split the various passes into separate XSL files. I'm much happier with the structure of the files now and the workflow works fine in Eclipse. Our release system works with ant. I can process the files like this:

<xslt basedir="src-xml" style="src-xml/preprocess_1.xsl" in="src-xml/original.xml" out="src-xml/temp_1.xml" />
<xslt basedir="src-xml" style="src-xml/preprocess_2.xsl" in="src-xml/temp_1.xml" out="src-xml/temp_2.xml" />
<xslt basedir="src-xml" style="src-xml/preprocess_3.xsl" in="src-xml/temp_2.xml" out="src-xml/temp_3.xml" />
<xslt basedir="src-xml" style="src-xml/finaloutput.xsl" in="src-xml/temp_3.xml" out="${finaloutput}" />

But this method, going via multiple files on disk, seems inefficient. Is there a better way of doing this with ant?

Update following Dimitre's suggestion

I've created myself a wrapper around the various other XSLs, as follows:

<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:fn='http://www.w3.org/2005/xpath-functions' xmlns:exslt="http://exslt.org/common">

<xsl:import href="preprocess_1.xsl"/>
<xsl:import href="preprocess_2.xsl"/>
<xsl:import href="preprocess_3.xsl"/>
<xsl:import href="finaloutput.xsl"/>

<xsl:output method="text" />

<xsl:template match="/">
    <xsl:apply-imports />
</xsl:template>

</xsl:stylesheet>

This has... not worked well. It looks like the document had not been preprocessed before the final output XSL ran. I should perhaps have been clearer here: the preprocess XSL files are modifying the document, adding attributes and the like. preprocess_3 is based on the output of ..._2 is based on ..._1. Is this import solution still appropriate? If so, what am I missing?

Jon Bright
  • 13,388
  • 3
  • 31
  • 46
  • The more efficient method is to perform a single, multipass transformation. The files can remain as they are -- they will be imported using `xsl:import` instructions. The savings are obvious -- just one initiation (loading of the XSLT processor) and termination, also eliminates the two intermediate files and their creation, writing into, closing and deleting. – Dimitre Novatchev Oct 18 '12 at 20:09
  • @DimitreNovatchev, that sounds good - I'll try it out tomorrow. You might want to formulate that as an answer rather than a comment? – Jon Bright Oct 18 '12 at 20:46
  • Jon Bright: Added as an answer. – Dimitre Novatchev Oct 18 '12 at 21:21
  • A single multi-pass transformation might be more efficient, but it's less modular - it makes it more difficult to reuse the code and assemble the pipeline in a different way. Ant also gains efficiencies by not redoing work that doesn't need redoing. Another approach would be to look at XProc, which is explicitly designed for writing pipelines of XSLT (etc) transformations. – Michael Kay Oct 19 '12 at 08:52

2 Answers2

1

The more efficient method is to perform a single, multipass transformation.

The files can remain as they are -- they will be imported using xsl:import instructions.

The savings are obvious:

  1. Just one initiation (loading of the XSLT processor).

  2. Just one termination.

  3. Eliminates the two intermediate files and their creation, writing into, closing and deleting.

Dimitre Novatchev
  • 240,661
  • 26
  • 293
  • 431
0

Hmm, you say I know about the trick with exsl:node-set, but you don't use it in your attempt ("Update following Dimitre's suggestion"). In case you don't know it, or for the others (like me) who don't know how to perform multipass transformation, here is a nice article: Multipass processing.

The drawback of this approach is that it requires engine specific xsl code. So if you know the engine, you could try this. If you don't know the engine, you could try with solutions from result tree fragment to node-set: generic approach for all xsl engines.

Looking at these sources one conclusion is sure: your current solution is more readable. But you are seeking efficiency, so some readability may be sacrificed.

Community
  • 1
  • 1
Jarekczek
  • 7,456
  • 3
  • 46
  • 66