Re: Alternate "parameters" draft

Alex Milowski wrote:
> I'm a little confused by:
> 
> "If no binding is provided for a parameter input port, a default
> binding is constructed. If the step's container has exactly one
> parameter input port, then this port is bound to it. If the container
> does not have exactly one parameter input port, then this port is
> bound to a document that consists only of an empty c:parameters
> element."
> 
> So, that means the in-scope parameters for the contained steps are
> "bound" to any
> unbound parameter input port, right?

Yes, except there aren't any in-scope parameters, only parameter input 
ports on the container.

If you have one parameter input port on a container, then (by default) 
the parameters automatically get passed through to the parameter input 
ports of the contained steps.

But if you have two or more parameter input ports on the container, then 
there's no obvious way to choose which set of parameters should get 
passed through to the parameter input ports of the contained steps, so 
none of them do.

> On 5/22/07, Norman Walsh <ndw@nwalsh.com> wrote:
>>
>> 5. There's room for argument about the names of things, of course. I
>>    implemented "parameter input ports" with a parameters=yes attribute on
>>    p:input as Jeni suggested. If we adopt this proposal in spirit, I
>>    think we could reasonably decided to introduce a p:parameter-input
>>    element instead.
> 
> I think a different name is required since the "input" could come
> from non-XML sources (i.e. the in-scope parameter values).

Under this proposal, there aren't any in-scope parameter values. 
Parameter input ports always take a single <c:parameters> document. This 
document can come from the parameter input port of a container step, or 
you can construct it easily using <p:parameter> rather than always 
having to use the usual document construction mechanisms, or you can use 
the normal document construction mechanisms. However you do it, the 
parameter input port always takes an XML document.

>> In the interest of full disclosure, points 2 and 4 interact a little
>> bit. If you happen to have a pipeline with a port named "parameters"
>> then you won't get exactly the current status quo behavior, but (1)
>> that's unlikely today and (2) you can easily work around it.
>>
>> Comments?
> 
> Are you expecting we'll change the definition of steps like p:xslt
> to have a parameter input port?

Yes (although you could default it).

> When the parameter input port is bound and some number of
> p:parameter elements are also specified, what happens?

Under my original proposal, it was an error. Under Norm's draft, the 
<p:parameter> elements are added at the end of the parameter document, 
such that they override any parameters with the same name specified in 
the document you bound to the input port. That works, I think.

Cheers,

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

Received on Wednesday, 23 May 2007 21:29:00 UTC