Default binding of parameter input ports

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:

> +1 one from me. I have been facing exactly the same problems you
> described. Especially explaining this to first time XProc users is not
> easy.
>
> I believe the main motivation for the current behavior was indeed the
> nonexistence of an undefined XPath context in 1.0 implementations. 

Ok. Good. Lots of positive feedback, no negative feedback. I'll add this
to the draft.

> Now, ehm, there is one more thing, sort of similar, that I find equally
> confusing/annoying. Consider this pipeline:
>
> <p:declare-step>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="source">...</p:input>
>     <p:input port="stylesheet">...</p:input>
>     <p:with-param name="foo" select="...">...</p:with-param>
>   </p:xslt>
> </p:declare-step>
>
> The example is invalid because the pipeline does not have a primary
> parameter input port (and the "parameters" port of p:xslt is therefore
> unconnected). Because of that, you have to do:
>
> <p:declare-step>
>   <p:output port="result"/>
>
>   <p:xslt>
>     <p:input port="source">...</p:input>
>     <p:input port="stylesheet">...</p:input>
>     <p:with-param name="foo" select="...">...</p:with-param>
>     <p:input port="parameters">
>       <p:empty/>
>     </p:input>
>   </p:xslt>
> </p:declare-step>
>
> My feeling is that just the presence of one or more p:with-param for a
> parameter port should be enough. Typically, I think you want to say: I
> want to pass params A and B to the step, and that's it. More rarely you
> want: pass params A and B, and whatever else was passed to as parameters
> to the owner pipeline.

I'm not sure I agree. The whole default parameter input port thing is
there to allow users to pass in new parameters. For stylesheets that
have dozens of parameters, I think it might still be the case that
users would like to pass in others from the command line, even though
the pipeline author has set a couple of them explicitly. 

Pipeline authors aren't necessarily going to remember to setup a
binding for that.

OTOH, your fix is to explicitly bind the port to p:empty, so you've
prevented what we intended anyway. My fix is to add a parameter input
port to the pipeline :-)

> What I am proposing is something like this:
>
> If there is a p:with-param for a parameter input port, that port gets
> *never* connected to the primary parameter input port of the owner
> pipeline automatically; if you want that, you can always use an explicit
> binding. If there is no p:with-param for a parameter port, the port gets
> connected to the primary parameter input port of the owner pipeline.

I guess I could live with that, but it's much more of a coin toss to
me. Parameters are pretty confusing, I really don't know if making the
rules more complex helps or hurts with respect to users figuring out
what they need to do.

> I often find myself adding p:empty bindings to parameter input ports,
> especially in pipelines that contain multiple steps that take
> parameters. In virtually all cases, only one of these steps reads the
> parameters from the owner pipeline; the other steps typically take the
> parameters from somewhere else:
>
> <p:xslt>...</p:xslt>
> ...
> <p:xquery>...</p:xquery>
> ...
>
> I guess I can live with the status quo (although I think it is a bit
> confusing at times), but I would like to know what others think of such
> a change.

Indeed. Users and implementors, please weigh in!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Birds are taken with pipes that imitate
http://nwalsh.com/            | their own voices, and men with those
                              | sayings that are most agreeable to
                              | their own opinions.--Samuel Butler