- From: James Fuller <jim@webcomposite.com>
- Date: Sat, 3 Aug 2013 22:14:25 +0200
- To: Jostein Austvik Jacobsen <josteinaj@gmail.com>
- Cc: Geert Josten <geert.josten@dayon.nl>, Norman Walsh <ndw@nwalsh.com>, XProc Dev <xproc-dev@w3.org>, Florent Georges <fgeorges@fgeorges.org>
On 3 August 2013 13:59, Jostein Austvik Jacobsen <josteinaj@gmail.com> wrote: > ...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> Or we could consider as an amend/change to p:try for vnext. As for the other suggestions; my thoughts are for vnext that a full blown macro approach, whilst very powerful, seems to be out of scope for vnext, others though may have different opinions. At this stage, we have much to do to make the existing language concise and more usable. though I think its worth a discussion on the proposed elements and new behavior - 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 will raise a point to add to future meeting agenda. J > > ...? > > > > > 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 20:14:52 UTC