Re: Variables and parameters

/ Rui Lopes <rlopes@di.fc.ul.pt> was heard to say:
|>   <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 ''.

*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}"

| 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.

|> 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.

| 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.

I'd like to avoid that level of complexity if we can.

|> 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().

If we can get agreement that all parameters must be strings (I'm not
confident we will), then I'd rather let it be implicit than force
users to write "string(/foo)", but I could be persuaded to go either
way.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
XML Standards Architect
Sun Microsystems, Inc.