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

Re: Variables and parameters

From: Rui Lopes <rlopes@di.fc.ul.pt>
Date: Thu, 11 May 2006 20:56:39 +0100
Message-ID: <446396F7.7060306@di.fc.ul.pt>
To: Norman Walsh <Norman.Walsh@Sun.COM>
Cc: public-xml-processing-model-wg@w3.org
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: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().


Received on Thursday, 11 May 2006 19:56:53 UTC

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