Re: Alternate "parameters" draft

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?

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

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

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


-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 23 May 2007 21:15:56 UTC