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

Re: Option or parameter?

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 26 Apr 2007 07:32:09 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87y7kfnzgm.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> 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.

It seems to me that parameters ought to pass down automatically. If I
have an XSLT step down inside a p:for-each, I'd like to be able to refer
to parameters I specified on the command line, even if I didn't mention
them on the p:for-each.

| 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:xslt>
|     <p:input port="stylesheet">
|       <p:document href="foo2html.xsl" />
|     </p:input>
|     <p:parameter name="config:view" select="$view" />
|     <p:import-parameter name="*" />
|   </p:xslt>
| </p:pipeline>
| 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 <p:import-parameter>.

Hmm. So

<p:import-parameter name="config:*" ns=""/>

imports all the "config:*" parameters but moves them all to no-namespace?

I can see how that could be handy...

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | If brute force doesn't work, maybe
http://nwalsh.com/            | you're not using enough brute force.

Received on Thursday, 26 April 2007 11:32:21 UTC

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