Re: On parameters

/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| I can certainly live with this, and I agree that the basic analysis is
| correct, but I have a few residual concerns:
|
| 1) We are grabbing another port name for pipeline use;

Yes. There seem to be two possibilities: grab the name "parameters" or
add some sort of 'type' attribute to inputs so that authors can
indicate which one(s) are for parameters.

I hadn't quite thought that all the way through. The pipeline
processor needs to know what inputs are for parameters so that it can
do error checking and potentially have a different defaulting story
for them.

| 2) I'm not sure about the whole defaulting situation. . .
|
| Let's look at the latter a bit.  At least one possible story would be:
|
|  a) If a step-type is not declared to take a 'parameters' input, then
|     an instance of that step only sees parameters explicitly specified
|     with <p:parameter> directly within that instance;
|
|  b) If a step-type is declared to take a 'parameters' input, and a
|     binding for that port is given on an instance of that step, then
|     that instance sees all and only the parameters presented on that
|     port and the parameters explicitly specified with <p:parameter>
|     directly within that instance (and the latter take precedence);

I'm with you on a) and b)

|  c) If a step-type is declared to take a 'parameters' input, and no
|     binding for that port is given on an instance of that step, then
|     that instance sees all and only the #pipeline-parameters and the
|     parameters explicitly specified with <p:parameter> directly within
|     that instance (and the latter take precedence).
|
| So you can 'protect' a step _type_, by not declaring a 'parameters'
| input for it, but if a step type _is_ declared to have a 'parameters'
| input port, then you have to do
|
|   <p:input port="parameters">
|    <p:empty/>
|   </p:input>
|
| to 'protect' an _instance_ of such a step type.  I guess I think
| that's about right.

Or, alternatively, if you don't provide a binding for the parameters
port, then the default is the same as a) (i.e., no parameters by
default).

In this case, you have to add a parameters port and

  <p:input port="parameters">
    <p:pipe step="main" port="parameters"/>
  </p:input>

if you want the pipeline parameters passed through.

I think that's ok too.

I expect that most pipelines, like most stylesheets, will never have any
parameters:

<p:pipeline name="main" xmlns:p="http://www.w3.org/2007/03/xproc">
<p:input port="source"/>
<p:output port="result"/>
<p:xinclude/>
<p:xslt>
  <p:input port="stylesheet">
    <p:document href="docbook.xsl"/>
  </p:input>
</p:xslt>
</p:pipeline>

So when the author wants to allow them, he or she will have to add:

<p:pipeline name="main" xmlns:p="http://www.w3.org/2007/03/xproc">
<p:input port="source"/>
<p:output port="result"/>
<p:input port="parameters" maybe-some-type="parameters"/> <!--this-->
<p:xinclude/>
<p:xslt>
  <p:input port="parameters">                         <!--and this-->
    <p:pipe step="main" port="parameters"/>
  </p:input>
  <p:input port="stylesheet">
    <p:document href="docbook.xsl"/>
  </p:input>
</p:xslt>
</p:pipeline>

That doesn't seem like too large a burden.

I suppose it's a little simpler if we say that there is exactly one
parameter port and it's named "parameters" and you don't have to/may not
declare it.

There's definitely a little more complexity here, but I think I still
find my arguments compelling. Certainly, with my implementor's hat on,
I find them hugely compelling.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The wonder is, not that the field of
http://nwalsh.com/            | stars is so vast, but that man has
                              | measured it.--Anatole France