Re: Option or parameter?

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| I agree with Alex V. that we should make the distinction between
| options and parameters a lot clearer.

Indeed.

| At a theoretical level, I propose that we say that options are used
| when the names of arguments are known in advance (at the design of the
| component), and that parameters are used when the names of arguments
| aren't known in advance. Since you can't know what parameter names are
| going to be passed in to a pipeline, you shouldn't rely on particular
| parameters being present.

I agree that all the option names are known in advance, and there
might be additional parameter names at runtime.

I'm having a hard time composing crisp wording to describe the
distinction, but I'll take a stab at explaining what I think it is.

Options provide configuration information for the pipeline processor
to use when it is setting up the steps. Things such as whether or not
the XInclude processor outputs xml:base attributes, what initial mode
the XSLT processor should use, whether validation should be strict or
lax. Options are strictly local to the step on which they occur,
they aren't in the environment and they aren't visibile to other
steps.

Parameters are information that the processor passes blindly to the
step. The processor neither knows nor cares what they do or what
they're for, it just assumes the step will know. Any parameter visible
to a compound step is also visible to all its contained steps.
Parameter values are passed in the environment. Parameters may be
shadowed.

| At a practical level, I propose that we say that parameters can never
| be accessed using variable references within XPath expressions. So you
| can do:
|
| <p:pipeline>
|   <p:option name="schema-uri" />
|   <p:load>
|     <p:option name="href" select="$schema-uri" />
|   </p:load>
|   ...
| </p:pipeline>
|
| but can't do:
|
| <p:pipeline>
|   <p:parameter name="schema-uri" />
|   <p:load>
|     <p:option name="href" select="$schema-uri" />
|   </p:load>
|   ...
| </p:pipeline>

Ouch! We've made exactly the opposite decision, I believe. At the moment
It's parameters, not options, that you can provide to a p:pipeline.

| That means the only way you can pass parameters into steps is through
| <p:import-parameter>. You can turn options into parameters, but you
| can't turn parameters into options.
|
| The consequences would be:
|
|  * it's OK for an option and a parameter to have the same name
|  * the eventual target for all parameters will be an atomic step that
|    accepts parameters, such as p:xslt
|  * pipelines will mostly use options rather than parameters

Except for spelling parameter "o" "p" "t" "i" "o" "n" and option
"p" "a" "r" "a" "m" "e" "t" "e" "r", I think I agree :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | To others we are not ourselves but a
http://nwalsh.com/            | performer in their lives cast for a
                              | part we do not even know we are
                              | playing.--Elizabeth Bibesco