RE: Annoyances with parameter input ports

> > 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.

I didn't mean replacing the binding. What I meant is that if you don't
provide an explicit binding, but you *do specify* at least one
p:with-param for the port, why couldn't this be sufficient? And if you
want to bind to the primary parameter input port of the containing
pipeline even so, you can use an explicit binding in addition to that.
And only if you didn't provide anything (no p:with-param, no binding),
then we would create the implicit binding to the primary  parameter
input port of the pipeline.

> 
> > 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>

No, I wanted to make it explicit in p:xslt that I don't want to connect
to the parameter port of the pipeline. I wanted p:xslt to see only
foo/bar, but nothing else that gets passed to the pipeline.

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

Exactly.

> 
> > 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.

Sorry, I don't understand. I just wanted to make it sufficient to
specify p:with-param without an explicit binding for  parameter input
ports. I didn't want to change any of the present behavior with respect
to overwriting parameter values by using different orders of
p:with-param, parameter bindings, etc.

Regards,
Vojtech

Received on Friday, 21 November 2008 13:28:21 UTC