- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Wed, 02 May 2007 19:37:06 +0100
- To: public-xml-processing-model-wg@w3.org
Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | I called them parameter sets before. Around about
> | http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0030.html
>
> At the end of that message, you have an example that uses two parameter
> sets, but I don't see how parameters get placed in those sets.
Thinking about it, the easiest syntax to adopt would be to just add a
'set' attribute on <p:parameter> and <p:import-parameter> and a 'use'
attribute on <p:import-parameter>. So you would do:
<p:pipeline name="my:parameter-set-example">
<p:parameter set="set1" />
<p:parameter set="set2" />
<p:xslt>
<p:import-parameter set="param" use="set1" />
<p:parameter set="param" name="extra" value="one" />
</p:xslt>
<p:xslt>
<p:import-parameter set="param" use="set2" />
</p:xslt>
</p:pipeline>
and call it with:
<my:parameter-set-example>
<p:parameter set="set1" name="foo" value="a" />
<p:parameter set="set2" name="foo" value="b" />
</my:parameter-set-example>
Resonable defaulting rules could mean that the 'set' attribute could be
omitted much of the time.
> | I do think it's unwieldy to use namespaces to name sets of parameters,
> | especially when the names of parameters can reasonably be QNames.
>
> It could be unweildy, but I think the unweildy cases are far enough from
> the common case that adding more complexity to make them less unweildy
> might not be worth it for V1.
Maybe. On the other hand, I don't want us to design v1 in such a way
that we can't add the extra functionality we need in v2 without
backwards-incompatible changes.
> | I am not suggesting that they can declare the (local) names of the parameters
> | that they accept: if they knew that, it'd be an option.
>
> Note that you couldn't, with the current language, prevent
>
> <p:parameter name="config:p1" />
> <p:parameter name="config:p2" />
>
> etc. Not that I think that's worth worrying about.
Presumably it's possible to add wording to the spec to say that when
<p:parameter> is the child of <p:pipeline> then its name attribute must
not hold a QName.
Cheers,
Jeni
--
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 2 May 2007 18:37:28 UTC