W3C home > Mailing lists > Public > xproc-dev@w3.org > November 2008

Re: precedence in calabash

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 18 Nov 2008 16:12:44 -0500
To: XProc Dev <xproc-dev@w3.org>
Message-ID: <m2bpwcn3g3.fsf@nwalsh.com>
"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

Received on Tuesday, 18 November 2008 21:13:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 November 2008 21:13:27 GMT