yax - an XProc (XML Pipeline) Implementation

By default implicit connections apears in black or in blue color, explicit connections appears in green color. You can change the appearance according your needs by setting the appropriate preferences. (By change colors keep in mind that default color for errors is red)

The file <pipeline filename>.portTrace.png contains the graphical representation of the pipeline which depicts the expected route the process will take over the ports. (This file will only generated if the automaticOutput attribut of the <porttrace> preference is set to 'yes'.)

The most simple pipeline is an empty pipeline:

<xproc:pipeline name="pipe1" 
    xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
    xmlns:yax="http://opsdesign.eu/yax/1.0">
</xproc:pipeline>
            
            

When you run such an empty pipeline you get a message that the pipeline will be bridged. In that case the pipeline construct has the same behaviour as the identity step.

            
...
Construct 'pipe1' is empty and will be bridged.
...
            
            

pipelines can contain nested components in an arbitrary (??) depth:

            
<xproc:pipeline name="pipe1" 
    xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
    xmlns:yax="http://opsdesign.eu/yax/1.0">
    <xproc:pipeline name="pipe1.1">
        <xproc:step name="step1" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="examples/transformation1.xsl"/>
        </xproc:step>
        <xproc:pipeline name="pipe1.1.1">
            <xproc:step name="step1" type="xproc:XSLT">
                <xproc:input port="stylesheet" href="examples/transformation2.xsl"/>
            </xproc:step>
            <xproc:pipeline name="pipe1.1.1.1">
                <xproc:step name="step1" type="xproc:XSLT">
                    <xproc:input port="stylesheet" href="examples/transformation3.xsl"/>
                </xproc:step>
            </xproc:pipeline>
        </xproc:pipeline>
    </xproc:pipeline>
</xproc:pipeline>
            
            
            

In comparision to other steps at <p:Load> the input port is replaced by an external content source. The consequence is a break of the pipeline chain at this point. That means that the content at the result port of the preceding component of of the <p:Load> step will be discarded except other components refer to it explicitly.

<p:Load> can be used to replace the initial content load via the input file start paramter. So with <p:Load> you can place the reference to input data into the pipeline and can access yax with a single reference to location of the pipeline document.

# java -classpath lib/yax-0.7.jar net.sf.yax.Yax [options]pipeline file location
            

you can use parameter references with the form ${<parameter name>} within href attribute (or parameter). This reference will be replaced by the value of parameter with the same name passed either by property file or by start parameter ('-D<parameter name>').

With a combination of start parameter and parameter references within the xproc script you can build your scripts in a more flexible way. Example:

# java -classpath lib/yax-0.7.jar 
       net.sf.yax.Yax 
       -Dexample.dir=examples 
       -Dtest.dir=test 
       -DoutputFilename=output1.xml 
       example1.xproc
            

<xproc:pipeline name="pipe1" 
    xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
    xmlns:yax="http://opsdesign.eu/yax/1.0">
    <xproc:step name="Load1" type="xproc:Load" href="${examples.dir}/${inputFilename}"/>
    <xproc:step name="Store1" type="xproc:Store" href="${test.dir}/${outputFilename}"/>
</xproc:pipeline>
            

In comparision to other steps at <p:Load> the input port is replaced by an external content source. The consequence is a break of the pipeline chain at this point. That means that the content at the result port of the preceding component of of the <p:Load> step will be discarded except other components refer to it explicitly.

<p:Load> can be used to replace the initial content load via the input file start paramter. So with <p:Load> you can place the reference to input data into the pipeline and can access yax with a single reference to location of the pipeline document.

# java -classpath lib/yax-0.7.jar net.sf.yax.Yax [options]pipeline file location
            

you can use parameter references with the form ${<parameter name>} within href attribute (or parameter). This reference will be replaced by the value of parameter with the same name passed either by property file or by start parameter ('-D<parameter name>').

With a combination of start parameter and parameter references within the xproc script you can build your scripts in a more flexible way. Example:

# java -classpath lib/yax-0.7.jar 
       net.sf.yax.Yax 
       -Dexample.dir=examples 
       -Dtest.dir=test 
       -DoutputFilename=output1.xml 
       example1.xproc
            

<xproc:pipeline name="pipe1" 
    xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
    xmlns:yax="http://opsdesign.eu/yax/1.0">
    <xproc:step name="Load1" type="xproc:Load" href="${examples.dir}/${inputFilename}"/>
    <xproc:step name="Store1" type="xproc:Store" href="${test.dir}/${outputFilename}"/>
</xproc:pipeline>
            

As you can see in the graphic the fop step requires XML-FO as input.

Also it is possible to define a reference source for each when clause:

               
<xproc:pipeline name="pipe1" 
   xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
   xmlns:yax="http://opsdesign.eu/yax/1.0">
   <xproc:step name="trans1" type="xproc:XSLT">
      <xproc:input port="stylesheet" href="test/transformation1.xsl"/> 
   </xproc:step>
   <xproc:choose name="choose1" type="xproc:XSLT">
      <xproc:when name="when1" test="/test1">
         <xproc:input port="ref" href="test/chooseInput1.xml"/>
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:when>
      <xproc:when name="when2" test="/test2">
         <xproc:input port="ref" href="test/chooseInput2.xml"/>
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>            
      </xproc:when>
      <xproc:otherwise name="otherwise">
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:otherwise>
   </xproc:choose>
   <xproc:step name="trans3" type="xproc:XSLT">
      <xproc:input port="stylesheet" href="test/transformation3.xsl"/> 
   </xproc:step>
</xproc:pipeline>
                                             
            

If you do not define at least one reference port:

               
<xproc:pipeline name="pipe1" 
   xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
   xmlns:yax="http://opsdesign.eu/yax/1.0">
   <xproc:step name="trans1" type="xproc:XSLT">
   </xproc:step>
   <xproc:choose name="choose1" type="xproc:XSLT">
      <xproc:input port="ref" href="test/chooseInput0.xml"/>
      <xproc:when name="when1" test="/test1">
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:when>
      <xproc:when name="when2" test="/test2">
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>            
      </xproc:when>
      <xproc:otherwise name="otherwise">
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:otherwise>
   </xproc:choose>
   <xproc:step name="trans3" type="xproc:XSLT">
      <xproc:input port="stylesheet" href="test/transformation3.xsl"/> 
   </xproc:step>
</xproc:pipeline>
                                             
            

triggers an error message at the first when element:

construct 'when1': reference port not found.
               
            

You can also equip all elements of the choose/when/otherwise construct simultaniously with a reference port. In that case the reference port of the choose element triggers the generation of an implicit reference port at each when element. But the implicit reference ports take no effect because explicit ports always have priority. They regain effect when the explicit ports will be (also partitially) erased.

               
<xproc:pipeline name="pipe1" 
   xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
   xmlns:yax="http://opsdesign.eu/yax/1.0">
   <xproc:step name="trans1" type="xproc:XSLT">
      <xproc:input port="stylesheet" href="test/transformation1.xsl"/> 
   </xproc:step>
   <xproc:choose name="choose1" type="xproc:XSLT">
      <xproc:input port="ref" href="test/chooseInput0.xml"/>
      <xproc:when name="when1" test="/test1">
         <xproc:input port="ref" href="test/chooseInput1.xml"/>
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:when>
      <xproc:when name="when2" test="/test2">
         <xproc:input port="ref" href="test/chooseInput2.xml"/>
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>            
      </xproc:when>
      <xproc:otherwise name="otherwise">
         <xproc:step name="trans2" type="xproc:XSLT">
            <xproc:input port="stylesheet" href="test/transformation2.xsl"/> 
         </xproc:step>
      </xproc:otherwise>
   </xproc:choose>
   <xproc:step name="trans3" type="xproc:XSLT">
      <xproc:input port="stylesheet" href="test/transformation3.xsl"/> 
   </xproc:step>
</xproc:pipeline>
                                             
            

or more sophiticated with additional differenciating catch clauses:

<xproc:pipeline name="pipe1" 
    xmlns:xproc="http://www.w3.org/TR/2006/xproc/1.0"
    xmlns:yax="http://opsdesign.eu/yax/1.0">
    <xproc:try name="try1">
        <xproc:group name="group1">
            <xproc:step name="group1step1" type="xproc:XSLT">
                <xproc:input port="stylesheet" href="examples/transformation2.xsl"/>
            </xproc:step>
        </xproc:group>
        <xproc:catch name="catch1" exception="EmptyResult">
            <xproc:step name="catch1step2" type="xproc:XSLT">
                <xproc:input port="stylesheet" href="examples/transformation1.xsl"/>
            </xproc:step>
        </xproc:catch>
        <xproc:catch name="catch2" exception="FileNotFound">
            <xproc:step name="catch2step2" type="xproc:XSLT">
                <xproc:input port="stylesheet" href="examples/transformation1.xsl"/>
            </xproc:step>
        </xproc:catch>
        <xproc:catch name="catch">
            <xproc:step name="catchstep2" type="xproc:XSLT">
                <xproc:input port="stylesheet" href="examples/transformation1.xsl"/>
            </xproc:step>
        </xproc:catch>
    </xproc:try>
</xproc:pipeline>
                                             
                  

How ever, each <p:try>/<p:catch> construct has to contain at least the general catch clause.