W3C home > Mailing lists > Public > xproc-dev@w3.org > August 2013

Re: custom non-atomic steps?

From: Jostein Austvik Jacobsen <josteinaj@gmail.com>
Date: Sat, 3 Aug 2013 13:59:02 +0200
Message-ID: <CAOCxfQdKpNz+-O7J+nohp4Cy-D7yo-smwidxKtcjfHut8PC_4g@mail.gmail.com>
To: Geert Josten <geert.josten@dayon.nl>
Cc: Norman Walsh <ndw@nwalsh.com>, XProc Dev <xproc-dev@w3.org>, Florent Georges <fgeorges@fgeorges.org>
Geert: yes, that's perfect for a compound step!

What about multi-container steps though? Could it be useful to define our
own version of p:choose or p:try?

Maybe instead of...

<p:try>
    <p:group>...</p:group>
    <p:catch name="catch">
        <p:choose>
            <p:xpath-context>
                <p:pipe step="catch" port="error"/>
            </p:xpath-context>
            <p:when test="xpath to check for presence of error with QName
err:ERR01">
                ...
            </p:when>
            <p:when test="xpath to check for presence of error with QName
err:ERR02">
                ...
            </p:when>
            <p:otherwise>
                ...
            </p:otherwise>
        </p:choose>
    </p:catch>
</p:try>

...I would like to write it more compactly as...

<px:try>
    <px:group>...</px:group>
    <px:catch code="err:ERR01">
        ...
    </px:catch>
    <px:catch code="err:ERR02">
        ...
    </px:catch>
    <px:catch>
        ...
    </px:catch>
</px:try>

...?




Jostein


On 31 July 2013 21:48, Geert Josten <geert.josten@dayon.nl> wrote:

> Hi Jostein,
>
>
>
> How close to what you had in mind would be something like this?
>
>
>
>                <p:declare-step type="my:if">
>
>                               <p:input port="source" sequence="true"
> primary="true"/>
>
>                               <p:input port="parameters" kind="parameter"/>
>
>                               <p:output port="result" primary="true"/>
>
>
>
>                               <p:option name="test" required="true" />
>
>
>
>                               <p:choose>
>
>                                             <p:when test="$test">
>
>
> <p:apply-subpipeline />
>
>                                             </p:when>
>
>                                             <p:otherwise>
>
>                                                            <p:identity/>
>
>                                             </p:otherwise>
>
>                               </p:choose>
>
>                </p:declare-step>
>
>
>
>                <my:if>
>
>                               <p:with-option name="test" select="xpath
> test">
>
>                                             <p:pipe port="metadata"
> step="load"/>
>
>                               </p:with-option>
>
> <p:add-attribute match="/*" attribute-name="something"
> attribute-value="something"/>
>
>                </my:if>
>
>
>
> Not as advanced as your suggestion, rather the stupid simplest I could
> come up with close enough to at least look what you tried.. ;-)
>
>
>
> Kind regards,
>
> Geert
>
>
>
> *Van:* Jostein Austvik Jacobsen [mailto:josteinaj@gmail.com]
> *Verzonden:* woensdag 31 juli 2013 20:42
> *Aan:* Florent Georges
> *CC:* Norman Walsh; XProc Dev
>
> *Onderwerp:* Re: custom non-atomic steps?
>
>
>
> I'm not sure if I'm a fan of introducing a precompiler (I like to think of
> this feature as higher order functions rather than macros, even though what
> I outlined might be closer to a way to define macros). The XProc processor
> needs to be able to throw a meaningful error with the filename and line
> number of where the error occured.
>
>
>
>
> Jostein
>
>
>
> On 31 July 2013 18:14, Florent Georges <fgeorges@fgeorges.org> wrote:
>
> On 30 July 2013 19:52, Norman Walsh wrote:
> > Jostein Austvik Jacobsen writes:
>
>   Hi,
>
>
> >> 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.
>
> > I don't think it's been discussed. It's not clear how to describe a
> > custom step in a standard way.
>
>   If we are considering the "macro" approach, if we take the
> initial example again:
>
>     <my:if test="...">
>        <my:xpath-context .../>
>        [ sub-pipeline ]
>     </my:if>
>
> being equivalent to:
>
>
>     <p:choose>
>        <p:when test="...">
>           <px:xpath-context .../>
>           [ sub-pipeline ]
>        </p:when>
>        <p:otherwise>
>           <p:identity/>
>        </p:otherwise>
>     </p:choose>
>
>   What about the following?:
>
>     <p:declare-macro type="my:if">
>        <p:input  port="source" primary="true"/>
>        <p:output port="result" primary="true"/>
>        <p:xslt>
>           <p:input port="stylesheet">
>              <p:inline>
>                 <xsl:stylesheet version="2.0">
>                    <xsl:template match="/my:if">
>                       <a:choose>
>                          <a:when>
>                             <xsl:copy-of select="@*"/>
>                             <xsl:apply-templates/>
>                          </a:when>
>                          <a:otherwise>
>                             <a:identity/>
>                          </a:otherwise>
>                       </a:choose>
>                    </xsl:template>
>                    <xsl:template match="my:xpath-context">
>                       <a:xpath-context>
>                          <xsl:copy-of select="node()"/>
>                       </a:xpath-context>
>                    </xsl:template>
>                    <xsl:template match="node()" priority="-1">
>                       <xsl:message terminate="yes">
>                          Unknown: <xsl:copy-of select="."/>
>                       </xsl:message>
>                    </xsl:template>
>                 </xsl:stylesheet>
>              </p:inline>
>           </p:input>
>           <p:input port="parameters">
>              <p:empty/>
>           </p:input>
>        </p:xslt>
>     </p:declare-macro>
>
>   This defines a "step like", but which is evaluated at compile-
> time (instead of at run-time), with the corresponding XML as input
> (here the my:if element), and the result is inserted in the lexer
> tree, replacing the initial "macro call".  Here the macro is just
> a stylesheet transforming the my:if into corresponding p:choose
> (actually in an alias namespace, here bound to "a:").
>
>
>   Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/
>
>
>
Received on Saturday, 3 August 2013 11:59:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:11 UTC