Scope of options

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

You can work around the problem with a group:

<p:pipeline>
  <p:option name="a" value="1"/>
  <p:group>
    <p:option name="b" select="$a"/>
    ...

I'm not 100% certain that this is going to interact well with the
defaulting story for inputs and outputs, but let's assume that's not a
problem.

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?

Let's assume that that's a solvable problem (though I don't see a
practical solution). I assume we adopted this restriction because it
simplifies the implementation burden of computing circularities and
the right order in which to initialize options.

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?

I think it is, but then consider this pipeline (stipulate that the px:uuid
step takes parameters, which I doubt it would in real life):

<p:pipeline>
  <p:option name="a" select=".">
    <p:pipe step="uuid" port="result"/>
  </p:option>
  <p:option name="b" value="1"/>

  <px:uuid name="uuid">
    <p:parameter name="something" select="$b"/>
  </px:uuid>
  ...

This pipeline must also be legal, but our rule about scoping of
options doesn't actually save the implementor the challenge of working
out the order in which options can be evaluated because b must be
computed before running uuid which must be run before a.

In the degenerate case, we get:

<p:pipeline>
  <p:option name="a" select=".">
    <p:pipe step="uuid" port="result"/>
  </p:option>

  <px:uuid name="uuid">
    <p:parameter name="something" select="$a"/>
  </px:uuid>
  ...

And now there's a circularity in the options so our rule about scoping
of options doesn't actually save the implementor the challenge of
writing that code either.

Ignoring the degenerate case, I suppose we could insist that authors
use grouping to work around this case too:

<p:pipeline>
  <p:option name="b" value="1"/>

  <px:uuid name="uuid">
    <p:parameter name="something" select="$b"/>
  </px:uuid>

  <p:group>
    <p:option name="a" select=".">
      <p:pipe step="uuid" port="result"/>
    </p:option>
  ...

But again we have the problem that we've stolen an option from the
p:pipeline.

And even if we insist that the authors use groups to construct legal
pipelines, it's not obvious to me that the code to check whether or
not the pipeline is legal is actually simpler than the code to just
work out the order. At which point, the user might reasonably ask, why
doesn't the processor just figure it all out and let me write what I
want.

I think we need to reconsider the scoping of options.

                                        Be seeing you,
                                          norm

[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2007Oct/0068.html
-- 
Norman Walsh <ndw@nwalsh.com> | The skill of writing is to create a
http://nwalsh.com/            | context in which other people can
                              | think.--Edwin Schlossberg