W3C home > Mailing lists > Public > xproc-dev@w3.org > February 2018

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

From: Christophe Marchand <cmarchand@oxiane.com>
Date: Mon, 26 Feb 2018 08:42:18 +0100
To: xproc-dev@w3.org
Message-ID: <2ead3b0f-070b-b358-72b9-1e1b07fa665e@oxiane.com>
Explaining to beginners how steps are connected is really difficult. And 
there are only "simple" implicit connections from steps to steps that 
directly follows each other. In my opinion, extending implicit 
connections through steps that do not have primary outputs will drive to 
horrible headaches for people how will try to teach XProc to beginners ! 
I can understand that this is quite obvious for an advanced user, but I 
suspect the cost to maintain such code will be awfull. So, I'd prefer 
keeping implicit connections simple, even if this suggestion allows to 
remove unrequired code.

For (2) and (3), I have no opinion ; as it's not implicit, it is 
visible, so explainable.

Best,
Christophe


Le 25/02/2018 à 13:42, Jan Pertermann a écrit :
> 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
>
>
Received on Monday, 26 February 2018 07:42:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 February 2018 07:42:41 UTC