Re: A parameters alternative

"vojtech.toman@emc.com" <vojtech.toman@emc.com> writes:
> An interesting idea. If I understand it correctly, the p:global
> collection sort of replaces the primary parameter input of the owner
> pipeline. But how would that work with recursive/nested pipelines
> where you may want to pass different parameters to the pipeline? Or is
> p:global really global, so that you can use it, for instance, as a
> repository for global variables?

I was thinking that p:global would be immutable. Any step that doesn't
explicitly name it's parameters gets the global ones. That works all
they way down into nested pipelines the same way the current port does
if rely on the implicit bindings.

I was thinking that p:none would be immutable too. It's there so that
a pipeline author can prevent globals from silently slipping through.

> I think the final solution should make it easy to:
> - pass a combination of two or more named collections to a step

I was thinking that the parameters option would take a list:

  <p:xslt parameters="p:global my:computed other:whatever">...

> - pass an extension (by constructing additional parameters manually in
> the pipeline) of a named collection to a step

That's what 'my:computed' is for above. We'd have to specify a precedence
order for them. We might want to allow a p:with-param to explicitly name
a set (or sets) of parameters too, so the author has complete control
of the precedence:

   <p:xslt parameters="p:none">
     <p:with-param sets="my:computed"/>
     <p:with-param sets="p:global"/>
     <p:with-param name="somename" select="'no matter what, this value wins'"/>
     ...
  </p:xslt>

> - override parameters in a named collection

I think that can be accomplished with secondary sets as well.

> Is your idea that p:parameters would somehow be able to do this? That
> might be possible, but I wonder what the verbosity/annoyance factor of
> such an approach would be. Using p:parameters might disrupt the
> original processing sequence and force the pipeline author to use more
> p:pipe bindings.

I haven't worked that out. You're absolutely right that we don't want
to force a whole bunch of annoying bindings if we can avoid it.

> Ideally, simple tasks, such as passing a single parameter to p:xslt,
> should be one (or two to three at worst) liners.

I'd expect p:with-param to still be available for adding a single
parameter to the step.

                                        Be seeing you,
                                          norm

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