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

Re: Options or parameters

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 02 May 2007 19:37:06 +0100
Message-ID: <4638DA52.80205@jenitennison.com>
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:import-parameter set="param" use="set1" />
     <p:parameter set="param" name="extra" value="one" />
     <p:import-parameter set="param" use="set2" />

and call it with:

     <p:parameter set="set1" name="foo" value="a" />
     <p:parameter set="set2" name="foo" value="b" />

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.


Jeni Tennison
Received on Wednesday, 2 May 2007 18:37:28 UTC

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