Re: Revisiting "fixing parameters"

"Toman, Vojtech" <vojtech.toman@emc.com> writes:
> Nice proposal. Regarding 4, does inheritance work regardless of the parameters name? In other words, if I have:
>
> <p:declare-step>
>   <p:option name="par" parameters="true"/>
>
>   <p:declare-step type="ex:step">
>     <p:option name="foo" parameters="true"/>
>     ...
>   </p:declare-step>
>
>   <ex:step/>
> </p:declare-step>
>
> will "foo" inherit the bindings of "par" from the enclosing pipeline?

Yes, I think so, though I'm not sure we gave that a lot of thought.
I suppose making the names significant would be a way of resolving the
multiple-parameter options case.

> Regarding 5 and pipelines with anonymous parameters, how would you
> pass parameters to such a pipeline? If you cannot, why bother with
> creating an empty anonymous parameters option and inheriting from
> it?

The idea was that if that's the "top most" pipeline, then the calling environment,
the API or the command line, could set those parameters in some implementation
defined way.

Right now we have an ugly confusing case. Consider:

  <p:declare-step>
    <p:input port="source"/>
    <p:output port="result"/
    <p:xslt/>
  </p:declare-step>

That's invalid because there's no where to define the parameters port for the
p:xslt step.

If we say that's valid, but there's no binding for the XSLT step, then that pipeline
is "closed" with respect to parameters. That seems like the wrong thing (though maybe
we're trying too hard here).

The anonymous hack lets that be valid but also lets parameters passed from
the command line to flow through.

> But I am actually wondering if the distinction that something is a
> parameter is really that important. Perhaps we could get rid of the
> notion of parameters altogether and introduce instead some
> convenience rules for inheriting options/variables that would:

That'd be wonderful!

>
> - allow for more or less the same "magic" that we expect with today's parameters
> - reduce the amount of <p:with-option name="filter" select="$filter"/>
> - and, related to the previous point, maybe get rid of some the problems with unbound options etc.
>
> The following might be too radical/simplistic/problematic, but what
> about simply introducing an "inherit" attribute on the
> p:option/p:variable element? If the processor encounters an unbound
> option/variable while evaluating the pipeline, it would search for
> the nearest in-scope option/variable with the same name that was
> declared as inherit="true".
>
> The main change for parameters would be that you would have to be
> careful about how you name the options (the names have to match),
> but suppose p:pipeline is equivalent to the following:
>
> <p:declare-step>
>   <p:input port="source">
>   <p:output port="result"/>
>   <p:option name="parameters" inherit="true"/>
>   ...
> </p:declare-step>
>
> then you will still be able to do things like:
>
> <p:pipeline> 
>   <p:xslt/>
> </p:pipeline>
>
> and be sure that the parameters passed to the pipeline will get passed to the p:xslt step.

How does that work. How does a parameter named "page-size" pass through?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com