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

Hi Achim,

when writing <p:somestep ... identity="true"> I don't want the step to exactly behave like a <p:identity>. A step with no primary output port will copy it's input to the output (as primary). If I need the common result of this step later in my script, I connect explicitly - here the @identity should play no role. In case of a step with a primary output port, it should work equally (even if the step has no primary input port). Do you think this is a consistent behaviour? Actually it is a short form for:

---
<p:otherstep name="o" />

<p:somestep />

(<p:sink />)
<p:identity>
    <p:with-input port="source">
        <p:pipe step="o" port="result"/>
    </p:with-input>
</p:identity>
---

Regards,
Jan


> -----Ursprüngliche Nachricht-----
> Von: Achim Berndzen [mailto:achim.berndzen@xml-project.com]
> Gesendet: Montag, 26. Februar 2018 14:42
> An: j.pertermann@srz.de
> Cc: xproc-dev@w3.org
> Betreff: 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 16:03:30 UTC