Re: Options or parameters

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
|> 4. Allow p:import-parameter to change the namespace of parameters.
|
| I am not sure we need this. I would consider this for V.next.

I'm not sure about waiting for V.next.

Consider a pipeline that runs several XSLT steps. A great many
stylesheet authors put all their parameters in no namespace. It's likely
that there's some XSLT parameter collision between stylesheets.

If we want XProc to be able to pass foo=1 to one XSLT step and foo=2
in another, where both values are set on the command line (for
example), then we'll need some mechanism. Using namespaces seems
reasonable.

And the cost of namespace renaming for p:import-parameter is pretty
small.

|> 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.

As Jeni suggested, if you know the names in advance, use options not
parameters.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Truth lies within a little uncertain
http://nwalsh.com/            | compass, but error is immense.