Re: precedence in calabash

"James Fuller" <james.fuller.2007@gmail.com> writes:

> consider pipe.xpl that comes with calabash ...if a source input port
> is defined it will output this as a kind of identity transform.
>
> a similar situation is the following pipeline;
>
> <p:pipeline name="pipeline"
>             xmlns:p="http://www.w3.org/ns/xproc"
>             xmlns:my="http://www.example.org/test/mine">
>
> <p:declare-step type="my:identity">
>     <p:input port="source"/>
>     <p:output port="result"/>
>     <p:identity>
>         <p:input port="source">
>             <p:inline>
>                 <test/>
>             </p:inline>
>         </p:input>
>     </p:identity>
> </p:declare-step>
>
> <my:identity/>
>
> </p:pipeline>
>
> where my:identity should IMHO behave in the same manner but I test
> <test/> element even when I define source input port at the
> commandline... is it my understanding of the spec that is incorrect ?

Yes, but it's an interesting case.

Inside a pipeline, the rules are clear: an input is bound to the
default readable port if (and only if) it does not have an explicit
binding. The p:identity step has an explicit binding, so that's the
binding that will (always) be used.

Recall that <p:identity> is the instantiation of a particular type of
step, declared elsewhere with <p:declare-step>.

On p:identity, the p:input serves *only* as a binding.

On a p:pipeline (or p:declare-step), the p:input serves as *both* a
*declaration* and a *default binding*.

When the processor calls the initial pipeline, it gets to provide
bindings for the ports on that pipeline that override the default
bindings.

Note that the same thing happens if you call a pipeline from inside
a pipeline:

  <p:pipeline>

    <p:declare-step type="ex:one">
      <p:input port="source">
        <p:inline><doc/></p:inline>
      </p:input>
      <p:output port="result"/>
      <p:identity/>
    </p:declare-step>

    <ex:one/>

  </p:pipeline>

The 'source' input to the <ex:one/> step will be bound to the default
readable port (the 'source' input on the parent pipeline in this
case), and so the default provided in the declaration of ex:one will
never (and can never in this case) be used.

There's just enough wiggle room here for a pipeline processor (be it a
command line processor or one called via an API) to override the
default input bindings on the pipeline that it runs to get the
processing started. That's by careful design :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is not impossibilities which fill us
http://nwalsh.com/            | with the deepest despair, but
                              | possibilities which we have failed to
                              | realize.--Robert Mallet