- 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,
norm
--
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