Re: Variables and parameters

Norman Walsh wrote:
> Similar to the ideas we discussed today, here's my vision for
> parameters and variables. I think we want to allow variables
> to be set either as literals or as XPath expressions. Syntactically,
> there are probably a few ways we could do this, for the moment I'm
> going to use a 'value' attribute for literal values and a select
> attribute for XPath expressions:
> 
>   <p:param name="foo" value="foo"/>
>   <p:param name="bar" select="'bar'"/>
>   <p:param name="six" select="2+4"/>

I like this approach, it's similar to XSLT, therefore easily perceivable 
by xproc's potential users. However, I don't think we need @value, by 
comparing the two syntax options:

<p:param name="foo" value="foo" />
<p:param name="foo" select="'foo'" />

Maybe I'm missing something here, but I don't see why should we provide 
an extra attribute as a shortcut for ''. 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>


> I assume that top level variables can be specified by the user (on a
> command line, through some API, whatever). Of the variables that
> remain unspecified, I propose that that they be evaluated in order.
> Each XPath expression is evaluated with the context node set to an
> empty document and with the parameters previously declared in its
> context. So this works:
> 
>   <p:param name="one" value="1"/>
>   <p:param name="two" select="$one+$one"/>
>   <p:parma name="three" select="$two+$one"/>
> 
> But this is an error:
> 
>   <p:parma name="three" select="$two+$one"/>
>   <p:param name="two" select="$one+$one"/>
>   <p:param name="one" value="1"/>

I like it (except for the @value, as stated previously).


> 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? Maybe explicit scoping could be supplied to overcome 
it, such as:


<p:pipeline label="mypipe">
   <p:param name="foo" />

   <p:step name="something">
     <p:param name="foo" select="1" />
     <p:param name="bar" select="$mypipe.foo" />
...

Where $foo would default to the step's param. This feature may raise 
similar issues/problems if we allow pipeline composition in our language.


> Optionally, parameters can specify the document that should be the
> context node for evaluation:
> 
>     <p:param name="destination" ref="somelabel" select="/*/@label"/>
> 
> The value of the parameter is always string($expr).

Would the following param be an error? Or evaluated to string($expr)?

<p:param name="destination" ref="somelabel" select="/foo" />

I'd prefer raising an error, but I don't feel uncomfortable by 
evaluating to string().


---
Cheers,
Rui