Re: Parameters middle ground

Alex Milowski <alex@milowski.com> writes:
> I don't like how this intrudes on the parameter names.  This means you
> couldn't ever have a parameter named 'step'.

Sure, but by the same token, you can never use the syntactic shortcut
for an option named "name". So the precedent is set.

> Couldn't we just add either:
>
>    * an option to every step with parameters called 'parameters' that
> takes a whitespace separated list of ancestor step names (same
> semantics as you propose)

Yes, we could.

>    * a p:use attribute that could be used on the p:parameters
> attribute to do the what 'step' does.

Sure, but then you couldn't use p:parameters to set a parameter named
p:use, so...

> I'd prefer a syntax outside of p:parameters as "inheriting" parameters
> is a more complex use case and so a more complex (but not onerously
> so) syntax is justified.
>
> Another option is:
>
>    <p:parameters param1="value1" param2="{$value2}">
>       <p:use step="main"/>
>       <p:use step="other"/>
>       ...
>    </p:parameters>
>
> which would have the effect of merging "main" and "other" and then
> overriding/setting param1/param2.

Yeah. But the body of p:parameters is presumably a binding for the
context item for expressions, so that's kind of complicated.

                                        Be seeing you,
                                          norm

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