- From: Geert Josten <geert.josten@daidalos.nl>
- Date: Wed, 12 Oct 2011 18:21:03 +0200
- To: Matthieu Ricaud-Dussarget <matthieu.ricaud@igs-cp.fr>, "xproc-dev@w3.org" <xproc-dev@w3.org>
Hi Matthieu, About the input of p:error. You are right, there was already a p:input port="source" there. It would have made sense to have it on p:choose instead, but that is not possible. The p:identity just before is what gets closest, it supplies a primary input for all choose alternatives. The p:xpath-context (as suggested by Norm, thnx!) is interesting as well, but only applies to the when tests.. Kind regards, Geert -----Oorspronkelijk bericht----- Van: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] Namens Matthieu Ricaud-Dussarget Verzonden: woensdag 12 oktober 2011 17:08 Aan: xproc-dev@w3.org Onderwerp: Re: New to Xproc Question : conditionnal "output port" definition? Hi Geert, Once again, thanks a lot for your help. > <p:xslt ... name="xslt"/> > <p:store .../> > ... > <p:error ...> > <p:input port="source"> > <p:pipe step="xslt" port="result"/> > </p:input> > </p:error> I thought the input port of <p:error> shall contains the error message itself (within <p:inline> for example). I guess I have to get information on how to deal with error code and message to display. Anyway the problem is just above : <p:when test="count(distinct-values(/igs:aggregate/doc/pages/page/@viewportX))!=1"> <p:error ...> </p:when> My guess is that the xproc processor is not able to perform the xpath test above because it can't define a context node at this point of the pipeline... because just above is a <p:store> which doesn't through any output! > Another option, which is most often easier, is to put a p:identity with such an input binding after p:store: Yes you are right, it works ! And I now understand why my former xslt step direct after <p:store> works : I piped the input to the good step ... jumping back over the <p:store>. Cool that's clear ! > But since this is a common case, it is worthwhile to declare a helper step to do that. 100% agree ! > I wrote the following, which combines a p:store with such input rerouting, together with a p:choose so the p:store is only done if a debug parameter was passed through.. I actually don't know how to use such a self define step. My xpl file starts with <p:declared-step> element : It seems I can't add a <p:declared-step> within my root element <p:declared-step>. I thought I should put it in another xpl document and then import it from my current xpl with <p:import> but... It's seems <p:import> is not allowed as child of <p:declared-step>. Maybe I should use <p:pipeline> as root element but I actually thought it was better to start with <p:declared-step> so I can really understand binding concepts in Xproc. But this consideration is a bit out of the subject : I will keep the <p:identity> solution and go further with my pipeline. Later I'll try to make it more simple and maybe modular. Thanks again for your response. Matthieu
Received on Wednesday, 12 October 2011 16:21:29 UTC