Re: Scope of options

Norman Walsh wrote:
> (This originally arose as part of another thread[1])
> 
> Consider the following pipeline:
> 
> <p:pipeline>
>   <p:option name="a" value="1"/>
>   <p:option name="b" select="$a"/>
>   ...
> 
> We decided that was not allowed. (Although I don't think the spec is
> sufficiently clear on this point.)

Did we? That seems like a mistake to me. I think we should say that the 
definition(-and-binding) of an option (eg a <p:option> that's a child of 
<p:pipeline>) defines a variable binding that's then visible to all 
following siblings and their descendants. On the other hand, the 
*binding* of an option (ie a <p:option> that's a child of a step 
element) doesn't set up a variable: it's only used to provide a binding 
for the invocation of the step.

So you can do what you have above, but you can't do:

   <my:step>
     <p:option name="a" value="1" />
     <p:option name="b" value="$a" />
   </my:step>

(unless, of course, there's an 'a' option in-scope during the step 
invocation).

This is the same as in XSLT: when you declare a parameter, the parameter 
binding is visible to other parameter declarations; when you bind a 
parameter (with <xsl:with-param>) then that's not counted as a variable 
binding in the scope of the template invocation.

> It does raise the problem that the *pipeline* no longer has an option
> named "b". How should I write this pipeline so that it has two options
> "a" and "b" where "b" gets the value of "a" by default if no value is
> specified by the caller?

That's precisely why an option should be able to refer to any 
previously-declared option. (Note that circularity isn't an issue if an 
option can only refer to one that appears earlier in its container step.)

> Now consider this pipeline:
> 
> <p:pipeline>
>   <p:option name="a" select=".">
>     <p:pipe step="uuid" port="result"/>
>   </p:option>
> 
>   <px:uuid name="uuid"/>
>   ...
> 
> Does anyone think that's not a legal pipeline?

Well, me. And the spec I think. In 5.11 (p:pipe) it says:

   "In all cases except the p:output of a compound step, it is a static
    error (err:XS0022) if the port identified by a p:pipe is not in the
    readable ports of the step that contains the p:pipe."

The <p:option> here isn't the <p:output> of a compound step. The 
readable ports of the step that contains the <p:pipe>: the <p:pipeline> 
in the above. It's not clear from the spec what the readable ports are 
of a <p:pipeline>, but I don't think it includes the outputs of the 
steps that it contains.

FWIW, I do think the <p:pipe> in the <p:option> should be able to point 
to an *input* of the pipeline.

Cheers,

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

Received on Thursday, 18 October 2007 20:12:38 UTC