- From: Jostein Austvik Jacobsen <josteinaj@gmail.com>
- Date: Thu, 18 Jul 2013 16:12:47 +0200
- To: Geert Josten <geert.josten@dayon.nl>
- Cc: XProc Dev <xproc-dev@w3.org>
- Message-ID: <CAOCxfQe9pmv7X+DCMTY59E4aTXATSp2xCEZ-VEKeLgerUuZ_hQ@mail.gmail.com>
Hmm, not really. I was thinking more like the ability to for instance define your own "if" step. I find myself often doing this: <p:choose> <p:xpath-context> <p:pipe port="metadata" step="load"/> </p:xpath-context> <p:when test="xpath test"> <!-- do stuff --> </p:when> <p:otherwise> <p:identity/> </p:otherwise> </p:choose> when what I would like to do is this: <p:if test="xpath test"> <p:xpath-context> <p:pipe port="metadata" step="load"/> </p:xpath-context> <!-- do stuff --> </p:if> "p:if" might be coming in v.next (I see it mentioned in the wiki), but it might be useful to define other kinds of custom steps as well. It could be possible to declare that "this step accepts a subpipeline", maybe in a way similar to this: <!-- required new features: - p:subpipeline: a new element which declares that the step accepts a subpipeline. Has a boolean required attribute which defaults to true. Has an optional container attribute which is a QName defining the name of the container this subpipeline should be wrapped in (used when you have multiple subpipelines). - p:with-subpipeline: a new element which is a placeholder for the subpipeline provided when calling the step. If the subpipeline is declared as required, then a default subpipeline can optionally be provided inside the p:with-subpipeline. - p:pipe does not have to be wrapped in a p:input when used to call an atomic step; it would be connected automatically to the primary input. So you could say <p:identity><p:pipe step="main" port="source"/></p:identity> and it would work fine. - p:pipe can be invoked as an atomic step when used in a subpipeline; it works the same way as if you wrap it inside a p:input[@port="source"] wrapped inside a p:identity --> <p:declare-step type="px:if" name="if"> <p:input port="source"/> <p:output port="result"/> <p:option name="test" as="xpath"/> <p:subpipeline name="main"> <p:input port="source"> <p:pipe port="source" step="if"/> </p:input> <p:output port="result"/> </p:subpipeline> <p:subpipeline name="xpath-context" container="px:xpath-context" required="false"> <p:input port="source"> <p:pipe port="source" step="if"/> </p:input> <p:output port="result"/> </p:subpipeline> <p:group name="xpath-context"> <p:output port="result"/> <!-- will be replaced by the subpipeline wrapped in px:xpath-context --> <p:with-subpipeline name="xpath-context"> <p:pipe port="source" step="if"/> </p:with-subpipeline> </p:group> <p:split-sequence> <p:with-option name="test" select="concat('/*[',$test,']')"> <p:pipe step="xpath-context" port="result"/> </p:with-option> </p:split-sequence> <p:count/> <p:choose> <p:when test="not(.='0')"> <!-- will be replaced by the subpipeline which is not wrapped in anything --> <p:with-subpipeline name="main"/> </p:when> <p:otherwise> <p:identity/> </p:otherwise> </p:choose> </p:declare-step> This step could be invoked for instance like this: <px:if test="xpath test"> <px:xpath-context> <p:pipe port="metadata" step="load"/> </px:xpath-context> <p:add-attribute match="/*" attribute-name="something" attribute-value="something"/> </px:if> There might be some obvious problems with what I've outlined above which I haven't thought of, but I think it would be cool (and useful) to be able to declare custom non-atomic steps (that's the right term, right?). Jostein On 18 July 2013 15:04, Geert Josten <geert.josten@dayon.nl> wrote: > Do you mean something like this? > > > > > https://github.com/grtjn/xproc-ebook-conv/blob/master/src/nl/grtjn/xproc/ebook/main.xpl > > > > (also note the imports at the top..) > > > > Cheers, > > Geert > > > > *Van:* Jostein Austvik Jacobsen [mailto:josteinaj@gmail.com] > *Verzonden:* donderdag 18 juli 2013 14:53 > *Aan:* XProc Dev > *Onderwerp:* custom non-atomic steps? > > > > Has custom non-atomic steps (steps where you can provide one or more > subpipelines upon invocation) been discussed as a possibility in XProc > v.Next? It would for instance allow us to define our own custom syntactic > sugar. > > > > Jostein >
Received on Thursday, 18 July 2013 14:13:35 UTC