Re: Do we need computed parameters in V1?

Jeni Tennison wrote:
> If I can't set parameters based on information in an XML document, then 
> I can't use a config file as an input to the process. Instead, I have to 
> dynamically generate the pipeline, and run that. This is both much more 
> complicated for me as a user (code to generate code always is), and 
> limits my choice of pipeline implementations to those that offer a 
> "execute-pipeline" component.

You don't have to dynamically generate the pipeline.  Instead you do:

<p:pipeline name="my:create-manifest">
   <p:declare-input port="document" />
   <p:declare-parameter name="wrapper-name"/>
   ...
   <p:for-each name="create-svgs">
     <p:declare-input port="document" source="document" />
     <p:declare-output port="result" ... />
     ...
   </p:for-each>
   <p:step name="agg" type="p:aggregate">
     <p:input port="documents" step="create-svgs" source="result" />
     <p:parameter name="wrapper" select="$wrapper-name" />
   </p:step>
</p:pipeline>

Now, you have to specify a parameter of the wrapper name--which makes 
the invocation more complex.  But you don't have two inputs, which makes
the invocation less complex.  For some, this will be easier to
understand and use and for others it will probably be less so.

The output of the pipeline is the svg aggregate.  When you invoke the
pipeline, you specify the location to which the aggregate is serialized.
As such, you need one less step and no "save" is needed.

On my pipeline impl, the previous pipeline's invocation was:

xproc mysvgs.xpd document=input.xml config=config.xml

but you have to create the 'config.xml' for each invocation.  Also
the pipeline has no output as there is a 'save' at the end.

My suggested pipeline's invocation is:

xproc -p wrapper-name=bingo mysvgs.xpd input.xml

or

xproc -o location.xml -p wrapper-name=bingo mysvgs.xpd input.xml

I can't say there is a significant difference in invocation in terms
of complexity for the user.  Certainly my suggested pipeline is less
complex as there is less going on.  But if the handling of configuration
gets much more complex, that will probably cease to be the case.

--Alex Milowski

Received on Wednesday, 18 October 2006 15:14:54 UTC