Options or parameters

I think this thread turned up a significant issue:

  http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0150.html

I want to resolve this issue this week.

I find Jeni's example completely compelling:

> Let me take another tack. Take as a starting point an XSLT 2.0 step:
> 
> <p:xslt2>
>   <p:input port="stylesheet">
>     <p:document href="foo2html.xsl" />
>   </p:input>
>   <p:option name="initial-mode" select="$view" />
>   <p:import-parameter name="*" />
> </p:xslt2>
> 
> Let's say that we want to provide an easier interface to calling the
> foo2html.xsl stylesheet, and wrap it in a pipeline. Currently, this has to be:
> 
> <p:pipeline name="my:foo2html">
>   <p:input port="source" />
>   <p:output port="result" />
>   <p:parameter name="initial-mode" required="yes" />
>   <p:parameter name="*" />
>   <p:xslt2>
>     <p:input port="stylesheet">
>       <p:document href="foo2html.xsl" />
>     </p:input>
>     <p:option name="initial-mode" value="$initial-mode" />
>     <p:import-parameter name="*" />
>   </p:xslt2>
> </p:pipeline>
> 
> and I replace my original <p:xslt2> with:
> 
> <my:foo2html>
>   <p:parameter name="initial-mode" select="$view" />
>   <p:import-parameter name="*" />
> </my:foo2html>
> 
> I had to make three changes here: change the name of the step (as expected),
> remove the <p:input> (as expected), and change the <p:option> to <p:parameter>
> (as completely unexpected).
> 
> What's more, now my stylesheet works differently. Turns out it had an
> initial-mode parameter declared, and now it's picking up the value from the
> pipeline environment! Along with all the other parameters, used to configure the
> pipeline and the steps that the pipeline calls, that are flying around in the
> pipeline.
> 
> By comparison, if <p:parameter> is reserved for passing parameters into
> stylesheets (and other components that require arbitrary name/value pairs) then
> I only have to make the expected changes in the call in the original pipeline,
> and I don't end up with naming clashes.

I believe the following proposal addresses this issue:

1. Add in-scope options to the environment; treat options and parameters
   in exactly the same way with respect to scoping and shadowing.

2. Allow compound steps to declare both options and parameters.

3. Make variable references in XPath expressions refer to *options*
   instead of parameters.

4. Allow p:import-parameter to change the namespace of parameters.

So, given:

   <p:pipeline xmlns:p="..." xmlns:config="...">
     <p:option name="per-page" value="30"/>

     <p:group>
       <p:parameter name="config:items-per-page" select="$per-page"/>
       <p:xslt>
         <p:import-parameter name="config:*" ns=""/>
         ...
       </p:xslt>
     </p:group>
   </p:pipeline>

The value of $per-page is 30 (or whatever was passed to the pipeline).
The p:group calculates a parameter named config:items-per-page from
the pipeline option value. What gets passed to the XSLT step is a
parameter named "items-per-page" (in no namespace) with the value
specified for config:items-per-page on the group.

The distinction between options and parameters then becomes simply that
the names of options are all known in advance. The names of parameters
may not be.

In particular, I might have passed other parameters in the config
namespace to the pipeline and they would all get passed to the XSLT
step even though the pipeline hasn't a clue what their actual names
are before the pipeline is executed.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything we love, no doubt, will pass
http://nwalsh.com/            | away, perhaps tomorrow, perhaps a
                              | thousand years hence. Neither it nor
                              | our love for it is any the less
                              | valuable for that reason.--John Passmore