Re: Scope of options

This whole option situation is ugly.

On the one hand, I want options on pipelines to work like parameters
in XSLT:

<p:pipeline type="px:mypipe">
  <p:option name="key" value="my-default-key"/>
  <p:option name="token" select="concat('stuff',$key,'more stuff')"/>
  ....
</p:pipeline>

So that if I pass in a different key value, I get a different token
value automatically.

On the other hand, I want options on atomic steps to work like
with-param in XSLT:

<p:option name="match" value="MATCHSTUFF"/>
<p:add-attributes>
  <p:option name="match" value="//a[@foo]"/>
  <p:option name="attribute-value" select="$match"/>
</p:add-attributes>
 
So that the value of the attribute-value option is "MATCHSTUFF" not
"//a[@foo]".

Maybe the simplest thing to do is use p:with-option on atomic steps
and p:option on compound steps and declare-step.

Now that makes me think that if we want these things to be just like
param and with-param in XSLT, maybe the kindest thing we can do is
name them p:param and p:with-param.

But we can't do that because we've already got this great big ball of
complexity under the rubric parameters; having p:parameter and p:param
is just insane, we can all agree, I hope.

We've got this other related wrinkle that we use p:option in places
where "option" doesn't make a lot of sense:

  <p:group>
    <p:option name="uuid" select="px:uuid()"/>
    ...
  </p:group>

There's no way to "call" a group, so that's really a p:variable. I note
also that because we don't have any way of distinguishing between options
and variables, it's impossible to write:

  <p:pipeline>
    <p:option name="cannot-be-changed-by-the-caller" value="magictoken"/>
    ...
  </p:pipeline>

We could fix this with p:variable, if we wanted to introduce another
concept into the mix.

Actually, thinking about it a little more, I guess we don't have to
use p:with-option. We could finesse the problem and say that the
options that are in scope are all of those *declared* by
preceding-siblings or *declared* by ancestors.

This relies on the terribly subtle distinction that a p:option with a
select attribute on a compound step is simultaneously a declaration
*and* the association of a default value. Whereas on an atomic step,
it's only the assignment of a value to an option declared elsewhere.

That does the least violence to the spec, I guess, but...all this
option/parameter subtlety is a little scary.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.