- 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