Re: Options or parameters

Norm,

Norman Walsh wrote:
> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
> | Norman Walsh wrote:
> |> 2. Allow compound steps to declare both options and parameters.
> |
> | I'm kinda happy with this for now. (I'll argue for renaming "p:option" to
> | "p:variable" in this context later.)
> 
> That's going to be a hard sell. I expect implementations to allow me
> to set values for options (and parameters) on the command line.
> There's precedent in XSLT for doing this with parameters and there's
> lots of precedent for command line options (so we can pun a little bit
> and overload that term).
> 
> Setting variables from the command line would strike me as quite odd.

You misunderstand me. I think that <p:option> as an initial child of 
<p:pipeline> makes absolute sense, because these are things that you set 
at the command line. I think that <p:option> as an initial child of 
<p:group>, <p:for-each> etc. is really weird, because you don't invoke 
<p:group>, <p:for-each> from the command line. Using the name 
<p:variable> in this context makes a lot more sense and gels with every 
programming language I know.

<p:variable> at the pipeline level (in addition to <p:option>) would 
mean you could calculate and reuse intermediate values without exposing 
them as pipeline options or using a <p:group>.

> |> 4. Allow p:import-parameter to change the namespace of parameters.
> |
> | Yes. I think this provides a reasonable way of passing separate bundles of
> | name/value pairs into the pipeline without being stuck with those namespaces
> | later.
> |
> | (If parameter bundles were given names we wouldn't need to do this.)
> 
> I think parameter bundles would be a pretty significant change, but if
> you really think it's a better answer, can you remind me where the
> proposal is?

I called them parameter sets before. Around about 
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Mar/0030.html

I do think it's unwieldy to use namespaces to name sets of parameters, 
especially when the names of parameters can reasonably be QNames.

> | That sounds right to me, except that I think the pipeline should
> | declare that it can accept parameters in the config namespace. Also,
> | it could be rewritten without the <p:group>:
> |
> | <p:pipeline xmlns:p="..." xmlns:config="...">
> |   <p:option name="per-page" value="30"/>
> |   <p:parameter name="config:*" />
> 
> If the significant feature of parameters is that they have names which
> aren't known in advance, I'm reluctant to require pipeline authors to
> declare them by name :-)

At the very least I'd expect pipelines that accept parameters to declare 
that they accept parameters with (something like):

   <p:parameter name="*" />

It doesn't seem a giant leap from there to say that they can declare the 
namespace of the parameters that they accept, with (something like):

   <p:parameter name="config:*" />

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.

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Wednesday, 2 May 2007 15:26:02 UTC