W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2007

Re: Option or parameter?

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 26 Apr 2007 09:17:27 +0100
Message-ID: <46306017.7050509@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | I just find the distinction between arguments that are known in
> | advance and arguments that aren't known in advance much clearer than
> | trying to work out whether an argument is used *to*configure* a step
> | or used *by* a step.
> To recap:
> - Options are what you pass to a pipeline, they're in the environment,
>   they can be shadowed, and you can refer to them with XPath
>   expressions (i.e., $option). Basically, they're what parameters are
>   in the current draft. :-)
> - You can also pass parameters to a pipeline, but the pipeline author
>   isn't expected to know the names of the pipelines in advance. You
>   can't refer to them with XPath expressions, $param is an error.
> Should they be passed around like options, in the environment, capable
> of being scoped, etc?

Yes, I think both options and parameters should be scoped lexically and 
can be shadowed. I don't think either should be automatically passed in 
to steps: you need to use <p:option>, <p:parameter> or 
<p:import-parameter> to pass them in.

Options must be declared and might be required. But I think a pipeline 
definition should only be able to specify the namespaces of the 
parameters it accepts, not say anything about particular parameters 
being required. For example, this is OK:

<p:pipeline name="my:foo2html">
   <p:input port="source" />
   <p:output port="result" />
   <p:option name="view" required="yes" />
   <p:parameter name="config:*" />
     <p:input port="stylesheet">
       <p:document href="foo2html.xsl" />
     <p:parameter name="config:view" select="$view" />
     <p:import-parameter name="*" />

Note that the only parameters that can get passed into the xalt step are 
in the config namespace, because only parameters in that namespace are 
legal in the pipeline. It could be an error to pass in parameters in 
other namespaces, or they could get dumped on the floor if we wanted to 
be slightly kinder to users.

I think it would be very helpful to have a way of coercing parameters 
from one namespace to another: perhaps using a ns attribute on 

Jeni Tennison
Received on Thursday, 26 April 2007 08:17:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC