Re: Variables and parameters

Hi,

Norm Walsh wrote:
> / Rui Lopes <rlopes@di.fc.ul.pt> was heard to say:
> | Maybe I'm missing something here, but I don't see why should we
> | provide an extra attribute as a shortcut for ''.
> 
> *Shrug* I could go either way. We could also say that the value
> attribute is an AVT in XSLT terms and allow value="{2+4}"

If variables and parameters can only be strings, then I prefer an AVT
(because the semantics of AVTs is that they create strings). If they can
be of other types, then I prefer a select attribute.

Even if we restrict parameters to being strings, I think that we're 
going to want to allow variables to be types other than strings. I'm not 
sure whether it makes sense to have different syntax for setting the 
values of variables and setting the values of parameters...

> | I'd like to suggest a
> | simple alternative to the value syntax (quite similar to XSLT's):
> |
> | <p:param name="foo">a literal value goes here</p:param>
> 
> Yes, we could do that.

If parameters and variables can only be strings, then I prefer an
attribute. If they can be of other types as well, then using the content
of <p:param> would be useful for embedding documents, e.g.

<p:param name="parameters">
   <xsl:params>
     <xsl:param name="foo" select="'foo'" />
     ...
   </xsl:params>
</p:param>

> |> Parameters specified on a component are evaluated by default with the
> |> context node an empty document and the parameters "in scope" available
> |> as variables.
> |>
> |>   <p:step name="something">
> |>     <p:param name="limit" select="$three+$two"/>
> |
> | Should this imply that the following pipe excerpt
> |
> | <p:pipeline>
> |   <p:param name="foo" />
> |
> |   <p:step name="something">
> |     <p:param name="foo" select="1" />
> |     <p:param name="bar" select="$foo" />
> | ...
> |
> | would be an error, $bar would evaluate to the step's $foo, to the
> | pipeline's $foo?
> 
> I think $bar = 1 in that case. Or we could make shadowing illegal.

I think we should make a clear distinction between *defining* parameters
and *setting* parameters.

<p:param> elements at the pipeline level *define* parameters and provide
default values for them (similar to <xsl:param> within <xsl:template>).
Pipeline parameters may be defined in terms of other pipeline
parameters, so that users don't have to specify all the pipeline
parameters each time the pipeline is invoked.

<p:param> elements at the step level *set* parameters (similar to
<xsl:with-param> within <xsl:call-template>). It doesn't make sense to
have some parameters within a step dependent on other parameters within
the same step, because it's always possible to provide the explicit
value. In the above example, if you wanted the 'bar' step parameter to
be set to 1 then you could just set it to 1.

(If the distinction between defining and setting parameters is 
confusing, perhaps it would be less so if we used <p:param> elements at 
the pipeline level and <p:with-param> or <p:set-param> elements at the 
step level.)

So in my opinion, in the above, the 'bar' parameter should be set to the
value of the 'foo' pipeline parameter, whatever that is.

I think it would be unreasonable to outlaw shadowing: users don't have
control over the names of the parameters used within steps, since these
are defined by the people who define components. And I think users are 
going to want to define pipelines that essentially shadow built-in 
components with a particular set of parameter values. For example, if 
the 'save' component had a bunch of parameters for the various 
serialisation options, then I might do:

<p:pipeline name="my:save">
   ...
   <p:param name="cdata-section-elements" value="" />
   ...
   <p:step name="p:save">
     ...
     <p:param name="indent" value="yes" />
     <p:param name="encoding" value="ISO-8859-1" />
     <p:param name="cdata-section-elements"
              select="$cdata-section-elements" />
     ...
   </p:step>
</p:pipeline>

It would be a real pain to force users to change parameter names in 
these cases.

Cheers,

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

Received on Friday, 12 May 2006 10:44:42 UTC