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

Re: Parameters and pipelines proposal

From: Jeni Tennison <jeni@jenitennison.com>
Date: Wed, 11 Jul 2007 21:38:00 +0100
Message-ID: <46953FA8.9050802@jenitennison.com>
To: public-xml-processing-model-wg@w3.org

Norman Walsh wrote:
> My thinking was that the only point in having a default would be to
> set some default params. And I didn't think we needed two ways
> to do that.
> 
> This is ok:
> 
>   <p:pipeline ...>
>     <p:parameter name="foo" value="bar"/>
>     <p:parameter name="bar" value="foo"/>
>     ...
> 
> And so is this:
> 
>   <p:pipeline ...>
>     <p:input port="parameters" primary="yes"/>
>     <p:parameter name="foo" value="bar"/>
>     <p:parameter name="bar" value="foo"/>
>     ...
> 
> But I didn't think we needed to allow this:
> 
>   <p:pipeline ...>
>     <p:input port="parameters" primary="yes">
>       <p:inline>
>         <c:parameter-list>
>           <c:parameter name="foo" value="bar"/>
>           <c:parameter name="bar" value="foo"/>
>         </c:parameter-list>
>       </p:inline>
>     </p:input>
> 
> But if you really feel strongly about it, I could be persuaded. It
> might be more consistent to treat it just like a default "ordinary"
> input, I guess.

I don't think people should be specifying default values for parameters 
anyway (because if you know the name of a parameter that your pipeline 
will receive, you should be using an option).

So personally I'd vote for mandating parameter inputs be empty and not 
allowing <p:parameter> here.

But if we're going to allow this, I don't see why we shouldn't allow 
both mechanisms: after all, we allow both when we invoke a step, and it 
could be described in exactly the same way here.

<p:parameter> looks very similar to <p:option>, which could be counted 
an advantage (though personally I see it as a disadvantage, given that 
it will help people get very confused about whether to use options or 
parameters). If we have it, I note that authors should be permitted to 
have *just* <p:parameter> elements without actually naming the default 
input; and if there are <p:parameter> elements at this level it should 
implicitly create an anonymous primary parameter input port.

Whatever the mechanism, you have the issue of whether the default 
parameter set gets overridden en-masse or individually. In other words, 
given that the pipeline above is invoked with:

   <...>
     <p:parameter name="foo" value="baz" />
   </...>

is the parameters input set to:

  (a) { foo: baz }
  (b) { foo: baz, bar: foo }

As I said before, I think the latter is more useful, and it's certainly 
what using individual <p:parameter> elements implies. Anyway, we need to 
specify it explicitly.

One last thing: can we rename <c:parameter-list> to <c:parameter-set> or 
<c:parameter-bindings> or <c:parameter-map> or something? 
<c:parameter-list> makes it sound as though the parameters are ordered, 
which they're not (in the set generated from the <c:parameter-set> element).

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Wednesday, 11 July 2007 20:38:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT