- From: Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>
- Date: Tue, 7 Mar 2017 08:16:00 +0100
- To: XProc Dev <xproc-dev@w3.org>
The main issue with dynamic evaluation of pipelines is that one doesn’t know in advance the ports and options. Calabash solves this by multiplexing the inputs and outputs and by wrapping option strings in a cx:options document. I see three main alternatives for dynamic evaluation in XProc 3. 1. Do as Calabash currently does, maybe with the exception that options become a map. 2. Put the inputs and outputs into a map, too. $input = map { "source": [$doc1, $doc2], "stylesheet": $xsl } So input and output will be plain options for p:eval? 3. Don’t introduce p:eval. Instead, introduce something like abstract step declarations similar to the ones that are provided for extension steps (declaration only, no subpipeline body). These declarations have an option abstract="true". They must not declare a port named "pipeline" because that’s where the pipeline document will be supplied when invoking this step. In our experience from using cx:eval (a lot), you always know the ports and options in advance for a specific invocation. Things don’t have to be as dynamic as they are now with cx:eval. It’s totally acceptable and even useful (for generating documentation or for static graph analysis, from an implementor’s point of view) to declare the step signatures in advance. Example for an abstract declaration: my_step_abstract.xpl: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:my="urn:my:xproclib" version="3.0" type="my:step" abstract="true"> <p:input port="source"> <p:inline> <doc>Hello abstract world!</doc> </p:inline> </p:input> <p:output port="result"/> </p:declare-step> Instantiation of such an abstract step may happen in two ways: a) The step will be imported and another p:declare-step document will be sent to the "pipeline" port. (It has to be a complete p:declare-step rather than a subpipeline because each implementation of an abstract step may use different p:imports or default connections.) So here’s an implementation: my_step_impl1.xpl: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:my="urn:my:xproclib" version="3.0" type="my:step"> <p:import href="my_step_abstract.xpl"> <p:documentation>Importing the abstract pipeline is optional. It will be checked during runtime whether an implementation has the same signature as the abstract declaration.</p:documentation> </p:import> <p:input port="source"> <p:inline> <doc>Hello world!</doc> </p:inline> </p:input> <p:output port="result"/> <p:identity/> </p:declare-step> This pipeline calls the step: <p:option name="my_step_impl" select="'my_step_impl1.xpl"/> <p:import href="my_step_abstract.xpl"/> <my:step> <p:input port="pipeline"> <p:document href="{$my_step_impl}"/> </p:input> </my:step> ⇒ <doc>Hello world!</doc> b) Alternatively, an implementation may be imported directly: <p:import href="my_step_impl1.xpl"/> <my:step> <p:input port="pipeline"> <p:document href="{$my_step_impl}"/> </p:input> </my:step> This approach could also approximately address Matthieu’s request for an override mechanism for p:import. Unlike xsl:import, it does not provide cascaded inheritance though. It rather provides an interface. Thoughts? Gerrit -- Gerrit Imsieke Geschäftsführer / Managing Director le-tex publishing services GmbH Weissenfelser Str. 84, 04229 Leipzig, Germany Phone +49 341 355356 110, Fax +49 341 355356 510 gerrit.imsieke@le-tex.de, http://www.le-tex.de Registergericht / Commercial Register: Amtsgericht Leipzig Registernummer / Registration Number: HRB 24930 Geschäftsführer: Gerrit Imsieke, Svea Jelonek, Thomas Schmidt, Dr. Reinhard Vöckler
Received on Tuesday, 7 March 2017 07:16:38 UTC