Re: Parameters

"Toman, Vojtech" <vojtech.toman@emc.com> writes:
> Well, the main difference is that in V1, the scope of parameters is
> bounded by the owner pipeline. This has two benefits: the pipeline
> makes it clear what its interface with regard to parameters is; and it
> can do whatever scary things internally, but these impl details don't
> percolate all the way to the end-user.
>
> In other words, V1 pipelines are encapsulated (pipeline A calling B
> needn't care about the internals of B), but the current proposal seems
> to break that. It smells of 'parameter hell' to me.

I don't think that's actually the case. Consider:

  <p:pipeline name="main">
     ...

     <p:pipeline type="ex:foo" name="subordinate">
        ...
        <p:xslt name="style"/>
     </p:pipeline>

     ...

     <ex:foo/>

In this example, whatever parameters are passed on the parameters port
to the main pipeline are also bound implicitly to the parameters port
on the ex:foo pipeline when it's called. And those get passed through
to the contained xslt step.

To prevent that, you'd have to say:

  <ex:foo>
    <p:input port="parameters"><p:empty/></p:input>
  </ex:foo>

It is true that in the p:parameters() function proposal, the user of
ex:foo has no way to control the parameters that the XSLT step will
see without doing some additional work. But they have the tools to do
it any way they'd like.

I think the 99% case is that it's harmless and useful to have the
parameters pass through "globally". For authors of the remaining 1%, I
think it's ok to make them work a little harder if it keeps things
*vastly* simpler for the 99%.

>> Thinking that through:
>> 
>> Suppose someone had a pipeline with an XSLT step and they've packaged
>> that for reuse as a step.  The XSLT step doesn't do anything with the
>> parameters option and so they get the default value which binds the
>> option to p:parameters('').
>> 
>> Now, someone uses that step within their pipeline and they set some
>> parameters on invocation.  Those parameters will be used by the XSLT
>> within the imported step.
>> 
>> Is this a good thing?  It depends on what you are doing.  If that XSLT
>> is complicated (e.g. the docbook stylesheets) and has many, many
>> parameters, being able to pass particular parameters to the XSLT step
>> contained in the imported pipeline easily is a good thing.  On the
>> other hand, if it causes the contained XSLT to do the wrong thing, that
>> is a bad thing.
>
> I agree. But in cases when it is not a good thing, the pipeline author
> should be able explicitly override the default behavior.

The author who writes the p:xslt step has complete control. The only
person who loses control in the new proposal is the person writing a
pipeline that uses a read-only third party library.

I think that's a fair trade for the reduction in complexity.

                                        Be seeing you,
                                          norm

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