RE: Parameters

> > Given that you have no control over the 3rd-party
> pipelines/libraries, I am worried that this may lead to completely
> unmaintainable mess.
> 
> I'm not certain how this is any different than today.  When you invoke
> someone's step, you can explicitly bind the parameters to whatever
> you'd like.  If they have internally used specific named sets of
> parameters without exposing control over that via an option, their
> library wouldn't be that usable.

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.

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

Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech

Received on Friday, 21 February 2014 10:45:25 UTC