Re: Scope of options

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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.

That seems better to me.

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

That certainly simplifies things, I guess. Are we all happy that the
pipeline above isn't legal?

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

Yes.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Don't use the impudence of a beggar as
http://nwalsh.com/            | an excuse for not helping him.--Rabbi
                              | Shmelke of Nicolsburg