Re: Parameter input ports

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| A couple of comments:
|
| 2.9 Parameters
|
| I read:
|
| Additionally, if a p:pipeline or p:declare-step does not declare any
| parameter input ports, but contains a step which has an unbound
| primary parameter input port, then an implicit primary parameter input
| port (named “parameters”) will be added to the pipeline. (If the
| pipeline declares another (non-parameter) port named “parameters”, the
| implicit primary parameter input port will be named “parameters1”. If
| that's not available, then “parameters2”, etc. until an available name
| is found.)
|
| Sorry if I missed the discussion about this, but I fail to see why we
| need to adopt a defaulting strategy for parameter inputs that is
| different than the one we have for document inputs. Adopting the same
| strategy would also avoid having those implicit names "parameters",
| "parameters1", ... created.

I don't follow. Our strategy for document inputs names them "source"
and "result" and makes it an error to attempt to define another port
with those names. Are you suggesting that we should do the same thing
for parameter inputs? Or are you suggesting that an implicit parameter
input port doesn't need a name, and so cannot be explicitly
referenced?

| The kind attribute distinguishes between the two kinds of inputs:
| document inputs and parameter inputs. An input port is a document
| input port if kind is specified with the value “document” or if kind
| is not specified.
|
| Shouldn't we also say there what the value of "kind" should be to
| specify that this is a parameter input? (i.e. parameter)

It does. The tableaux at the beginning of 5.1.2 specifies it and the
fourth paragraph below that explains it. Doesn't it?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A hen is only an egg's way of making
http://nwalsh.com/            | another egg.--Samuel Butler (II)