Re: XProc 3.0: Automatically connect primary ports passing sec output steps; sink/identity as an attribute on steps

Hi Jan,

interesting suggestions. Thank you. 

I really like proposal (2) having a general attribute on any step telling the processor to dump the results on the primary output port of that step. I think we will have to deal a little with the name of that attribute and whether we have to put it in XProc’s namespace, so it does not mingle with an option name on any user defined step. 

For proposal (2) I have a simple user extension step in my library called „transparent-store“. One can always argue whether we should add this to the standard library or ask the user to write it for herself.

With regard to proposal (1) I think this will not work out, because in XProc 3.0 we changed the status of output port "result“ of p:store to "primary". It is difficult to see this in the current version of the specs because @primary is not used there. But the port is primary because it is the only output port of "p:store" and @primary is not false. I will make this explicit as soon as we have refactored the repository.

The reason for making this change comes from user experience finding it very had to figure out for each step, whether the port "result“ is primary or not.

As a consequence in XProc 3.0 you will always have to write

<p:store href="...“ />
<p:sink />

because in 

<p:store href="…“ />
<p:store href="…“ />

the second p:store will save the document with the absolute uri were the first store wrote the result.

And the necessity of writing 
<p:store href="....“ />
<p:sink />

makes your third proposal <p:store href="....“ sink="true“ /> even more interesting.

BTW: I complete agree with Christophe that explaining auto connections to XProc beginners is really difficult. This is why I usually first introduce the explicit form (with p:pipe) and later mention the automatic connection as a kind of relief.

Greetings from Germany,
Achim


> Am 25.02.2018 um 13:42 schrieb Jan Pertermann <j.pertermann@srz.de>:
> 
> Hi,
> 
> first, many thanks to the team working on XProc 3.0 and also for your
> insights at XML Prague!
> 
> I have three proposals which I am not sure about, if they could work and
> also if that has been a topic in the past:
> 
> (1) Consider you need to connect a primary output port from step "p1" to a
> following step "p2" that has a primary input port. In between these steps
> you have one or more steps, that don't have a primary output port.
> 
> Wouldn't it be consequent to automatically connect the primary input/output
> ports? Because it is obvious, that "p2" cannot connect to a preceding step
> with no primary output, isn't it? That could save some lines of code
> defining explicit connections and it keeps the pipeline readable. On the
> other hand, I have the feeling, that this is a misconception and leads to
> confusion when trying to understand a pipeline; and break things for
> implementers :-)
> 
> Example 1:
> ---
> <p:identity name="p1">
>    <p:with-input port="source">
>        <c:result>Hello World!</c:result>
>    </p:with-input>
> </p:identity>
> 
> <p:store name="s1" href="test1.xml"/>
> 
> <p:store name="s2" href="test2.xml"/>
> 
> <p:add-attribute name="p2" match="/*" attribute-name="type"
> attribute-value="test"/>
> 
> <p:store name="s3" href="test3.xml"/>
> ---
> 
> The output of "s2" gets the same as that of "s1". The output of "s3" gets
> <c:result type="test">Hello World!</c:result>.
> 
> 
> (2) Secondly, I could imagine to have an attribute @sink="false|true" on any
> step as an alternative to <p:sink>. That would allow me to prevent passing
> the primary output from "p1" to the following steps in a simple way (by
> adding it to itself). Or it would allow me to prevent the implicit sink on a
> step without primary output.
> 
> Example 2:
> ---
> <p:identity name="p1">
>    <p:with-input port="source">
>        <c:result>Hello World!</c:result>
>    </p:with-input>
> </p:identity>
> 
> <p:store name="s1" href="test1.xml" sink="false"/>
> 
> <p:store name="s2" href="test2.xml" sink="false"/>
> 
> <p:add-attribute name="p2" match="/*" attribute-name="type"
> attribute-value="test"/>
> 
> <p:store name="s3" href="test3.xml" sink="false"/>
> ---
> 
> 
> (3) A contrary approach is an attribute @identity="false|true" allowing to
> pass through the primary input without changes.
> 
> Example 3:
> ---
> <p:identity name="p1">
>    <p:with-input port="source">
>        <c:result>Hello World!</c:result>
>    </p:with-input>
> </p:identity>
> 
> <p:store name="s1" href="test1.xml" identity="true"/>
> 
> <p:store name="s2" href="test2.xml" identity="true"/>
> 
> <p:add-attribute name="p2" match="/*" attribute-name="type"
> attribute-value="test"/>
> 
> <p:store name="s3" href="test3.xml" identity="true"/>
> ---
> 
> 
> (1) may be unorthodox, but (2) and (3) could help a lot to keep pipelines
> readable without changing the current spec too much. What do you think about
> it?
> 
>  
> Regards,
> Jan
> 
> 
> -- 
> Jan Pertermann, Dipl.-Ing (FH)
> XML-Applikationsentwickler
> 
> SRZ Berlin
> http://www.srz.de
> 
> 

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

http://www.xml-project.com

Received on Monday, 26 February 2018 13:42:24 UTC