RE: Something missing from the XProc spec...

> I'd like to create an XProc pipeline to process this test document but
> in order to do so I'd need a p:eval-pipeline step that had the ability
> to take the pipeline declared in t:pipeline, and apply it to 
> the t:input
> document. It could have the following signature:
> 
> <p:declare-step type="p:eval-pipeline">		
>      <p:input port="source"/>
>      <p:input port="pipeline"/>
>      <p:input port="parameters" kind="parameter"/>
>      <p:output port="result"/>
> </p:declare-step>
> 
> All that I'd then need to do is use the p:compare step to 
> check that the
> t:input document fragment matched the result from the p:eval-pipeline
> step.
> 
> I imagine that this feature would be a cinch for an EXProc extension
> and, in the fullness of time, I'll be implementing it in my own XProc
> processor 'Half-pipe'.

I was thinking about something like this before, too. A step that takes
an XProc pipeline and executes - that would be indeed a cool feature..

But the problem is that unless you restrict yourself to a specific class
of pipelines (like what you did: p:pipeline with a single document input
port, a single parameter input port, a single output port, no options),
you probably can't really define the signature of the p:eval-pipeline
step (or better: maybe you can, but it will probably look quite
scary...).

If we did what you are suggesting (support only certain classes of
pipelines), my personal feeling is that it would be really annoying for
the users to know that there is this great p:eval-pipeline step, but it
just does not work for their pipelines (because they use options, or a
document input port that takes a sequence of documents, or two output
ports, or...)

Just my two cents.

Regards,
Vojtech

Received on Wednesday, 11 March 2009 16:42:24 UTC