Re: Default binding of parameter input ports

On 23 Oct 2009, at 12:43, Norman Walsh wrote:
> "Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
>> 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).

Am I correct that:

<p:declare-step>
   <p:output port="result" />

   <p:xslt>
     <p:input port="source">...</p:input>
     <p:input port="stylesheet">...</p:input>
   </p:xslt>
</p:declare-step>

is invalid for the same reason? (With the possible fixes being to  
explicitly indicate that the 'parameters' input port for <p:xslt> is  
empty, or to create a primary parameter input port for the declared  
step.)

[snip]
>> 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.

FWIW, what I'd expect is, in:

<p:pipeline>
   <p:xslt>
     <p:input port="source">...</p:input>
     <p:input port="stylesheet">...</p:input>
     <p:with-param name="foo" select="..." />
   </p:xslt>
</p:pipeline>

for the parameters passed to the pipeline to get passed through to the  
XSLT, with the $foo parameter always provided with the default value  
that's specified on the <p:with-param>.

And in:

<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:xslt>
</p:declare-step>

for the XSLT to be passed only the $foo parameter and nothing else  
because the step declaration has no primary parameter input port.

In other words, I agree with Vojtech that the presence of the <p:with- 
param> should mean that the lack of connection to the XSLT steps  
primary parameter input port doesn't matter; but I don't agree with  
him that the presence of the <p:with-param> should cancel out the  
implicit connection between the primary parameter input port on the  
step and the one from its container.

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


What I've suggested above wouldn't completely solve this problem, but,  
with those suggestions in place, if you made the parameter input port  
on the owner pipeline non-primary then you could connect that port to  
only the relevant XSLT or XQuery step without needing to explicitly  
bind the primary parameter input ports of the other steps (so long as  
they were passed parameters with p:with-param). So it would help a bit.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Friday, 23 October 2009 19:14:35 UTC