Re: Annoyances with parameter input ports

Toman_Vojtech@emc.com writes:
> Section 5.1.2 (Parameter Inputs) says:
>
> "If no binding is provided for a primary parameter input port, then the
> port will be bound to the primary parameter input port of the pipeline
> which contains the step. ... It is a static error (err:XS0055) if a
> primary parameter input port has no binding and the pipeline that
> contains the step has no primary parameter input port."
>
> So what about this pipeline:
>
> <p:declare-step>
>   <p:input port="source"/>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="style.xsl"/>
>     </p:input>
>     <p:with-param name="foo" select="'bar'"/>
>   </p:xslt>
> </p:declare-step>
>
> Will it run, or not? In my interpretation, it will fail with err:XS0055
> ("It is a static error if a primary parameter input port has no binding
> and the pipeline that contains the step has no primary parameter input
> port."), but I find it a bit strange...

Yep. Strange it may be, but it's an error.

> I would sort of expect that specifying one or more p:with-param for the
> primary parameter input word would be "eqivalent" to providing an
> explicit binding for it. But that is not that case; to make the above
> mentioned pipeline run, I have to specify an explicit binding for the
> primary parameter input port of the p:xslt step:
>
> <p:declare-step>
>   <p:input port="source"/>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="style.xsl"/>
>     </p:input>
>     <p:with-param name="foo" select="'bar'"/>
>     <p:input port="parameters">
>       <p:empty/>
>     </p:input>
>   </p:xslt>
> </p:declare-step>

Yep. Because p:with-param's just feed into the parameter input port,
they are cumulative and don't replace the binding. If they *replaced*
the binding, then they couldn't be cumulative.

> As a convenience feature, we currently manufacture a default binding to
> the primary parameter input of the pipeline (if the pipeline has one),
> so the following example will work just fine:
>
> <p:declare-step>
>   <p:input port="source"/>
>   <p:input port="parameters" kind="parameter"/>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="style.xsl"/>
>     </p:input>
>     <p:with-param name="foo" select="'bar'"/>
>   </p:xslt>
> </p:declare-step>

Yep.

> However, because the manufactured default binding occurs last among
> other parameters, it can lead to quite confusing consequences (most
> often, the parameters read from the default binding may overwrite the
> parameters specified by p:with-param, etc.). So, to be really sure you
> always get what you want (in my case: I want to use only parameters
> provided by p:with-param, nothing else), you have to change the pipeline
> to:
>
> <p:declare-step>
>   <p:input port="source"/>
>   <p:input port="parameters" kind="parameter"/>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="style.xsl"/>
>     </p:input>
>     <p:with-param name="foo" select="'bar'"/>
>     <p:input port="parameters">
>       <p:empty/>
>     </p:input>
>   </p:xslt>
> </p:declare-step>

I think you'd be better off writing it like this:

<p:declare-step>
  <p:input port="source"/>
  <p:input port="parameters" kind="parameter"/>
  <p:output port="result"/>

  <p:xslt>
    <p:input port="stylesheet">
      <p:document href="style.xsl"/>
    </p:input>
    <p:input port="parameters">
      <p:pipe step="main" port="parameters"/>
    </p:input>
    <p:with-param name="foo" select="'bar'"/>
  </p:xslt>
</p:declare-step>

That has the effect that you always get foo=bar, but you don't prevent
pipeline users from passing other params.

> I find this quite confusing. You really have to be aware of these small
> tricky details when you write pipelines that rely on parameters or use
> them heavily.

Yep. Parameters suck, but the status quo sucks less than some of the
alternatives.

> Personally, I think that a solution to this could to make p:with-param
> equivalent to providing an explicit binding for the parameter input
> port, and to to update the definition of err:XS0055 so that it says
> something along the lines:
>
> "It is a static error (err:XS0055) if a primary parameter input port has
> no binding *and the step does not specify any p:with-param for the port*
> and the pipeline that contains the step has no primary parameter input
> port."
>
> With this change, the binding to the primary parameter input port of the
> pipeline would be manufactured only if no explicit binding is provided
> and no p:with-param is specified.
>
> Any opinions?

I don't like it because it then it wouldn't be possible to do what I
did above, allow arbitrary options but fix a few of them to specific
values.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | To others we are not ourselves but a
http://nwalsh.com/            | performer in their lives cast for a
                              | part we do not even know we are
                              | playing.--Elizabeth Bibesco