Re: dynamic evaluation in XProc 3.0

Hi all,

having thought about it for a while, I have to say I like Gerrit’s idea to introduce "abstract steps“ as a concept in XProc 3.0. It definitely leads to more robust pipelines, because the XProc implementation can do a lot of checks and find errors. This is, as far as my experience goes, very important when you do changes in a working dynamic step execution. Here I have a lot of trouble which is very difficult to debug or leads to very unreadable pipelines. Letting the implementation do the majority of checks seems to be a good solution.

I can see only two cons:
1) The „abstract step“-mechanism is not as flexible as p:eval, because, as Gerrit pointed out, I have to know the steps signature. I can easily think of use-cases, where one want to call a step without knowing this, for instance when writing very flexible steps for debugging or reporting. So may be it is not „abstract steps“ OR „p:eval“. But having „abstract steps“ is surely an advantage over p:eval in most cases.

2) „Abstract steps“ would be a new concept at the core of XProc 3.0, one more lesson to learn in a language which is already said to be difficult to learn. I think this might be an argument, but on the other hand: Many people use XProc without using (or needing) dynamic step evaluation. So both abstract steps and p:eval are features for advanced users, which will not be discussed on the first ten or twenty pages of a tutorial. That I CAN use abstract steps does not mean I have to use them and one can certainly learn XProc and do useful things without it. So abstract steps are a new concept, but one can master (a lot of) XProc without understanding it, if one does not need it.

Any other thought?

Greetings from Germany,
Achim

------------------------------------------------
Achim Berndzen
achim.berndzen@xml-project.com

http://www.xml-project.com




> Am 07.03.2017 um 08:16 schrieb Imsieke, Gerrit, le-tex <gerrit.imsieke@le-tex.de>:
> 
> 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 Monday, 13 March 2017 17:25:03 UTC