W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2011

RE: New to Xproc Question : conditionnal "output port" definition?

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>
Message-ID: <B26C615F8546A84C81165A7BC8BE61A020FC0F9492@EXMBXC01.ms-hosting.nl>
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,

-----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:error ...>
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 

> 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 
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.

Received on Wednesday, 12 October 2011 16:21:29 UTC

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