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

> 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 wouldn't name it horrible, but I share your thoughts on that. However (1) can illustrate another view on xproc I think - for beginners it is not easy, too, to handle secondary and primary in/outputs. It is something they will always get stuck at, because it is not visible (too). You may prevent a lot of unconnected primary outputs for a beginner.

Please regard my first proposal more like a general idea. Whereas the other proposals can be pragmatic solutions for the problem.

Regards,
Jan


> -----Ursprüngliche Nachricht-----
> Von: Christophe Marchand [mailto:cmarchand@oxiane.com]
> Gesendet: Montag, 26. Februar 2018 08:42
> An: xproc-dev@w3.org
> Betreff: Re: XProc 3.0: Automatically connect primary ports passing sec
> output steps; sink/identity as an attribute on steps
> 
> 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 09:57:14 UTC