Re: Options or parameters

Alessandro Vernet wrote:
> On 5/1/07, Norman Walsh <ndw@nwalsh.com> wrote:
>> 3. Make variable references in XPath expressions refer to *options*
>>    instead of parameters.
> 
> If a pipeline can accepts both options and parameters, you will have
> some use cases where you need to access options by name and others
> where you need to access parameters by name. A proposal that lets you
> access only options or parameters (but not both) won't be
> satisfactory.
> 
> For instance consider the case of a pipeline that automatically sets
> the value of a parameter based on the value of some other parameter
> you pass to the pipeline:
> 
> <p:pipeline name="my:foo">
>    <p:input port="source"/>
>    <p:output port="result"/>
>    <p:parameter name="param-a"/>
>    <p:parameter name="*"/>
>    <p:group>
>        <p:parameter name="param-b" value="$param-a"/>
>        <p:xslt2>
>            <p:input port="stylesheet">
>                <p:document href="foo2html.xsl"/>
>            </p:input>
>            <p:import-parameter name="*"/>
>        </p:xslt2>
>    </p:group>
> </p:pipeline>

The point of this proposal is that you wouldn't design a pipeline in 
that way: if you want to access a value within a pipeline then you must 
pass it in as an option rather than a parameter. So the above would be 
done with:

<p:pipeline name="my:foo">
    <p:input port="source"/>
    <p:output port="result"/>
    <p:option name="param-a" />
    <p:parameter name="*"/>
    <p:xslt2>
        <p:input port="stylesheet">
            <p:document href="foo2html.xsl"/>
        </p:input>
        <p:parameter name="param-a" value="$param-a" />
        <p:parameter name="param-b" value="$param-a" />
        <p:import-parameter name="*"/>
    </p:xslt2>
</p:pipeline>

This gives a clear, easily understandable distinction between options 
and parameters.

>> 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.
> 
> Yes, the name options are known in advance. But the names of
> parameters may be known in advance as well and have a particular
> significance to the pipeline. Imagine a pipeline that receives HTTP
> request headers. Headers are passed to the pipeline as parameters. The
> pipeline delegates part of the processing to some components passing
> all the headers. Here HTTP request parameters are seen by the pipeline
> as a bag of name/value, but it might still recognize some specific
> header and do something special with those headers. Hence the need to
> access those by name.

Under this proposal, the distinction between options and parameters is 
that if a component knows about particular argument names in advance, 
then they should be defined as options rather than parameters. In the 
case of HTTP headers, I would be in favour of defining each known HTTP 
header as an option, and having the component accept parameters for 
other (extension) headers.

How would you like to define the difference between options and parameters?

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

Received on Wednesday, 2 May 2007 08:17:38 UTC