- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 25 Apr 2007 19:43:25 +0100
- To: public-xml-processing-model-wg@w3.org
Norman Walsh wrote: > And with your proposal it would have been this, right? > > <p:pipeline name="my:foo2html"> > <p:input port="source" /> > <p:output port="result" /> > <p:option name="initial-mode" required="yes" /> > <p:xslt2> > <p:input port="stylesheet"> > <p:document href="foo2html.xsl" /> > </p:input> > <p:option name="initial-mode" value="$initial-mode" /> > <p:import-parameter name="*" /> > </p:xslt2> > </p:pipeline> > > and I replace my original <p:xslt2> with: > > <my:foo2html> > <p:option name="initial-mode" select="$view" /> > <p:import-parameter name="*" /> > </my:foo2html> Right. > (And actually, I think the import-parameter is either unnecessary or > not allowed but let's come back to that another time.) OK. > | By comparison, if <p:parameter> is reserved for passing parameters > | into stylesheets (and other components that require arbitrary > | name/value pairs) then I only have to make the expected changes in the > | call in the original pipeline, and I don't end up with naming clashes. > > The downside becomes that you can't compute the values of either > options or parameters from the values of other parameters. Right. You pass around sets of parameters, not individual ones, because you don't know what parameters are around and there's no way of testing for the presence of particular ones. On some occasions, if you know the stylesheet that you're using and the parameters that it contains, you might want to expose parameters as options in the wrapper. For example, I might create a pipeline wrapper like this: <p:pipeline name="my:foo2html"> <p:input port="source" /> <p:output port="result" /> <p:option name="results-per-page" required="yes" /> <p:xslt2> <p:input port="stylesheet"> <p:document href="foo2html.xsl" /> </p:input> <p:parameter name="results-per-page" select="$results-per-page" /> </p:xslt2> <p:xslt </p:pipeline> 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. Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
Received on Wednesday, 25 April 2007 18:43:31 UTC