XML Pipelines Part1

Home > Books > Tutorials and Training Guides > Pipeline Processing > XML Pipelines > XML Pipelines Part1

Recursive Pull Pipeline

In this section we show a recursive XQuery pipeline. The pattern employed here is a 'recursive pull' pipeline which introduces the concept of using active: URIs to execute pipelines.

Stage 1

<content>
{    doc("ffcpl:/content/lear.xml")//ACT[1]
}
</content>

try it!

The first stage of the pipeline is an XQuery which uses the doc() function to obtain lear.xml and applies an XPath to extract Act 1. It returns the result wrapped in a <content> root element.

Stage 2

<speeches>
{    doc("active:xquery+operator@ffcpl:/demos/xquery/pipeline/xq1.xml")//SPEECH    
}
</speeches>

try it!

Stage 2 also uses the doc() function, but this time it requests the active uri:

active:xquery+operator@ffcpl:/demos/xquery/pipeline/xq1.xml

When requested this active URI executes the stage 1 XQuery. Therefore stage 2 requests the result of stage 1 and then extracts all speech elements.

Stage 3

<gloucester>
{    for $speech in doc("active:xquery+operator@ffcpl:/demos/xquery/pipeline/xq2.xml")//SPEECH
    where $speech/SPEAKER = 'GLOUCESTER'
    return $speech
}
</gloucester>

try it!

Stage 3 executes stage 2 (which in turn executes stage 1) and filters the speeches down to those spoken by 'GLOUCESTER'.

Stage 4

<gloucester>
{    for $speech in doc("active:xquery+operator@ffcpl:/demos/xquery/pipeline/xq3.xml")//SPEECH
    for $line in $speech//LINE
    where contains( $line, 'France')
    return $speech
}
</gloucester>

try it!

Stage 4 executes stage 3 (which runs 2, which runs 1 ) and filters the speeches to those containing the word 'France'

You will have understood that this pattern of recursively invoking an XQuery pipeline by using active: URIs and the doc() function can be continued indefinitely. You will also recognize that the doc() function could invoke arbitrary URI addressed services and so XQuery can be used as a general pipeline scheduling language.

You might have concluded that, whilst this is a simple pattern, it is not a good way to develop pipelines; since each stage is hard coded to the next and there is no reusability or decoupling possible.

Stage 5

<idoc>
  <seq>
    <comment>
        ****************
        An XQuery Pipeline into an XSLT
        **********
        </comment>
    <instr>
      <type>xquery</type>
      <operator>xq4.xq</operator>
      <target>var:result</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:result</operand>
      <operator>style1.xsl</operator>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

try it!

Stage 5 is written as a DPML process, this provides a hint at how we can improve our pipeline design by sequencing the pipeline stages at a higher level.

This DPML process executes Stage 4 of the XQuery pipeline (which in turn runs stages 3, 2 and 1), it then passes the result to the XSLT accessor to be styled with a stylesheet.

DPML is a simple language for constructing and issuing active URI requests. DPML compiles the first instruction into the active: URI

active:xquery+operator@ffcpl:/demos/xquery/pipeline/xq4.xml

The second DPML instruction is converted to an active:xslt... URI request - finally the result is returned by setting this:response