dynamic evaluation in XProc 3.0

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