Re: Scope of options

On Thu, Feb 21, 2008 at 6:41 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> This whole option situation is ugly.

completely agree

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

another way to approach this might be the definition of an xproc
system function to define scope ?

the default could just be default context e.g. above would take
p:add-attributes match option value

perhaps this is like dynamic scoping in perl (with local()) where such
a xproc system function would in effectively create a step local copy
of a global option?

another 'workaround' could be something with namespaces .... but can't
see this helping things out.

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

I agree that this ball needs to be untangled and twined, though if you
are ever to pass the 2nd call, there is no way there is time to
address and tease out this issue.

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

ug....

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

I think investigating how some other languages manage dynamic scoping
might yield some ideas.

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

you outline the problem succinctly

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

I think  'least violence'  is in great tension with  'do what I mean'
with all this configuration/parameterization
(option/param/var/constant blah blah).

good luck, Jim Fuller

Received on Thursday, 21 February 2008 18:24:47 UTC