Re: Options or parameters

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norman Walsh wrote:
|> 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.
|
| Yes. Specifically, they are lexically scoped and must be passed explicitly into
| components.
|
|> 2. Allow compound steps to declare both options and parameters.
|
| I'm kinda happy with this for now. (I'll argue for renaming "p:option" to
| "p:variable" in this context later.)

That's going to be a hard sell. I expect implementations to allow me
to set values for options (and parameters) on the command line.
There's precedent in XSLT for doing this with parameters and there's
lots of precedent for command line options (so we can pun a little bit
and overload that term).

Setting variables from the command line would strike me as quite odd.

|> 3. Make variable references in XPath expressions refer to *options*
|>    instead of parameters.
|
| Yes.
|
|> 4. Allow p:import-parameter to change the namespace of parameters.
|
| Yes. I think this provides a reasonable way of passing separate bundles of
| name/value pairs into the pipeline without being stuck with those namespaces
| later.
|
| (If parameter bundles were given names we wouldn't need to do this.)

I think parameter bundles would be a pretty significant change, but if
you really think it's a better answer, can you remind me where the
proposal is?

|> 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.
|
| That sounds right to me, except that I think the pipeline should
| declare that it can accept parameters in the config namespace. Also,
| it could be rewritten without the <p:group>:
|
| <p:pipeline xmlns:p="..." xmlns:config="...">
|   <p:option name="per-page" value="30"/>
|   <p:parameter name="config:*" />

If the significant feature of parameters is that they have names which
aren't known in advance, I'm reluctant to require pipeline authors to
declare them by name :-)

|   <p:xslt>
|     <p:parameter name="items-per-page" select="$per-page" />
|     <p:import-parameter name="config:*" ns=""/>
|     ...
|   </p:xslt>
| </p:pipeline>
|
| but I suspect you just included it to demonstrate a compound step.

Yes. And to have an explicit, concrete example of the renaming.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Curiosity never killed anything except
http://nwalsh.com/            | maybe a few hours.