- From: Toman, Vojtech <vojtech.toman@emc.com>
- Date: Fri, 21 Feb 2014 05:44:40 -0500
- To: "public-xml-processing-model-wg@w3.org" <public-xml-processing-model-wg@w3.org>
> > 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